FAQ / Troubleshooting Checklist FAQ / Troubleshooting Checklist


Frequently asked questions




Frequently asked questions


There are several ways to get help from the community and engine team! But first of all you should try to search if your question already has been asked: If you are still unable to find any help, go to the Forum and ask your question! The Forum is monitored by the engine team and lots more people will read your question. The more forum points you have the higher prioritized your question will be.


A lot of engines out there call themselves multiplatform and if you look at the result that is also true: In the end the games made with these engines run on multiple platforms. However in most engines there will be a lot of "If - def" code included: if the platform is Xbox360 then do this.. .and if the platform is PS3 than to that. This leads to double work and lots of bugs since you have to make changes not only in one place. One of the core aims of the Delta Engine is to eliminate all "if-defs" in the all of the code, including the engine itself. If you look at any sample game you will find nothing platform specific in them, but even the whole engine is very platform and framework agnostic (except for specific framework implementations, which we shield into special projects that easily can be replaced). 

Therefore working with the Delta Engine feels very different from anything we have done before. Developing the game in Windows and using multi-touch features, our simulator, our performance tools, etc. works 100% the same way on all other supported platforms too. So once you add features or bugfixes in the engine or your game code for one platform, it will work all the way on all other platforms as well.

We could now tell you about our great simulators, profiling tools, UI and Scene Editors, how easy it is to setup graphical effects or use Multimedia, which is all important and works great of of the box, but what really is different about the Delta Engine is how you work with it. For example on iPhone we get touch and gesture events from the native iOS, but we handle then in the exact same way in Windows 7 (which can also do multi-touch) or XNA (which can do multi-touch in WP7). Or if you don't have a multitouch screen, just emulate it with the other input devices we support (Mouse, Keyboard, Accelerometers, Xbox or Wii controllers, Touch devices, etc.). Input is probably the hardest part to get right on all platforms without having the actual device in your hand (you should still test your game on your target devices), but that is exactly the point we want to make here: Even if you don't test it and just use the engine input features correctly, you game will feel right and exactly the same way as on Windows once you deploy it for the first time. It does not matter if you deploy to Android, iPhone, iPad, Windows Phone 7, Web, Xbox, PS Vita, etc., the game is all the same on each of those devices. And this feeling is something you will only get with the Delta Engine ;)


There might be other engines available for mobile, console or PC development, but no other engine is written in pure .NET code and supports so many platforms and features all at once so easily without any performance penalties. There will also be versions available in other languages like native C++, Java, VB, etc., but it all depends on what we hear from users. We could even argue that the optimized output code is usually better than what you get from 99% of other engines. Currently the engine focuses on mobile platforms, while still making it possible to create and test the game on Windows with Visual Studio for the programmers (it is just the greatest IDE for .NET developers). Any other IDE also works and for simple tasks you can use the Editor already.


  • Develop completely under Windows: No need to buy Macs for the whole team and to learn new tools to do an iPhone game. Use your PC and your favorite development tools.
  • Use .NET / C# or native C++: No need to learn dated programming languages such as Objective C. Work with managed code and be much more productive and with less errors. Currently working with C++? No problem - we also support native C++, check out our current build on github and contact us in the Forum if you need more support and help.
  • Open Source: No black box: You see how stuff works. You can change it if you want. You can optimize it for your game. You can write new modules or add existing libraries. Just look at how easy it is to integrate any framework like Physics, Rendering or even whole Graphics or Multimedia frameworks, you will find them all over the code.
  • Easy to learn: If you are already a Windows game programmer you do not need to learn anything new. Just use the Delta Engine and use the AppBuilder to port the game to your target platforms such as Web, iPhone, Android or Windows Phone 7.
  • Fast & lightweight: A lot of game engines have a lot of features in a black box. If you want to use only one of these features, you will need to add the whole black box. This is much better with an open system such as the Delta Engine. You can freely decide which parts of the engine you want and optimize it for your game. Add our advanced content system and you will get small game sizes which can be as small as natively programmed games. All our features are also highly optimized for speed - so you can just use them without having to invest months in speed optimizations.
  • Price: The Delta Engine is free for Windows and very reasonably priced for all the other platforms(about $15 gets you started, first 14 days are free if you are still unsure).

We think you can make great games with native code and with lots of other engines too, but using the Delta Engine makes it just much easier to bring your game to several different platforms all at once. We won't try to convince everyone to switch from C++ to C# or learn a different tool or programming language. Much rather we want to support what works best for each of our customers and support it in the best way possible. Thanks to our parsers it is now all possible.


The Delta Engine is based on a lot of .NET code we have written before. Since we already do .NET game development for 10+ years, we have a huge code base, lots of tools and libraries and a deep knowledge of .NET game development. We started applying all this and getting it to work on mobile platforms with early prototypes in 2009 and focused in 2010 our attention to building some smaller games resulting in the multiplatform game "ZombieParty" (Windows, Windows Phone, iPhone, Android, iPad). In 2011 SoulCraft was started and released in early 2012 (Android, iOS, Windows Phone, Windows 8), later in 2012 we founded the new Delta Engine company to split the efforts. We are highly committed to the Delta Engine and will continue to improve it for many years to come.


No, the overhead of .NET is negligible (check out Rico Mariani's blog). The important point for game developers is that .NET development is fast, testing is fast, writing games is fun and easy. The Delta Engine will increase your productivity a lot, this way you will have more time to tweak your games. The Delta Engine will also help you out a lot with the difficult task to optimize games for mobile platforms via special shaders, early warnings and lots of optimizations and caching to make your game code just work on all platforms. And if you don't like .NET, use another language like C++ or Java or ask us what language we should support next.


From the Forum

Short answer: Yes, its implemented and yes, you can do all that.

Long answer: Well, the content system is very dynamic due its nature of only requesting content at the very last moment when it is needed. However, for an iPhone game or even worse for a Windows Phone 7 game, you need to build and compile and optimize all content as much as possible before deploying it to the device and obviously before it is even started. It just does not make any sense to load content dynamically from the web, no mobile game does that, only for very minor updates and small parts like displaying a website or some html with images maybe. It is still possible to load some content yourself with the same API (e.g. via web calls or using a user images folder) you would use in a windows game, for example supporting user logos, but it should not be the norm for your game development because of performance and the problems described above.

That being said, it is up to you to go around the content system and load whatever content you like in whatever way you like. In windows you can load a texture from c:\mytexture.bmp, but that will simply not work on an iPhone or any non-windows platform in fact. Doing a http request is also possible (this is .NET after all and this kind of stuff is easy) and then sending that result to the image loader is also a piece of cake (remember, you got all the engine source code for that, even if a feature is missing, you can add it yourself). This will probably work on most platforms, but you have to be aware that there are some limitations (speed, is the user offline, what happens then, there are platforms like Windows Phone 7, which require all content to be baked into .xnb files first, http requests will still work, but using an uncompressed image will make your memory go up and your app might explode, etc.).


Well, content on the server can be public (visible to anyone), private (only visible to you) or protected (visible to others in a reduced version, but need access to use, good for selling stuff).

You probably mean the content on the client, which won't matter on most target platforms as the content is in some platform specific format and most users of iOS or Android or WP7 won't hack their device just to look at a boring texture ^^

For windows you can choose which modules you want to use (OpenGL, XNA, DirectX 9, 10, 11, etc.) and all content will be processed to run best on those platforms. Currently all the content (FallbackContent) for the engine is NOT processed, it is 1:1 was we put in there, which makes testing easy and allows extending content with ease. Normally you won't see this in games or applications. Take a look at our ZombieParty game (the free version ZombieHockey can be downloaded from our website, also coming as an tutorial game in v0.8.7), there are no simple files you can look at or modify that easily (mostly .rgba4 files are used here). Additionally you can write your own Content Importers/Exporters/Processors to encrypt or pack content in whatever way you like (in the future).


Currently our engine runs on Windows (XP, 2003, Vista, 2008, Windows 7, Windows 8, Windows 8.1, 32bit and 64bit), Android(Phones and Tablets), Web (HTML5+Javascript), and more platforms are already working and on its way for the next releases: iPhone, iPad, Windows Phone 7, Windows Phone 8, Xbox 360, PS Vita, Linux and Mac. More platforms are in early stages of development and not fully working yet, but we plan to include them as soon as all other platforms above are released: WiiU, 3DS, Xbox One, PS4, PS3, etc. Each platform complicates things a lot as not only all engine features, but also our build server and content server system needs to support each platform in every aspect. In early versions of Delta Engine we were limited by platforms that can execute .NET code, but since we now convert all code to whatever target platform and programming language, this is not longer an issue. Just more work for us, but all possible.


For all other platforms you will need a Delta Engine License. Only with this license you can then deploy on all platforms supported by the Delta Engine for testing or releasing into each App Store (more details will follow). You could just buy a license at the end of your development cycle, but your game will suffer as it will not have been developed and tested for mobile platforms. We highly recommend starting using the Delta Engine from the very first day with the target platforms in mind. You can add more platforms, but changing a desktop game to a mobile or console version is no easy task. Starting a game project and immediately testing in the first month how the very first bunch of ideas work on iOS, Android, Web and Consoles will make your game much better and quicker to develop.


Yes, we started early with Silverlight, but since that project has died at Microsoft we abandoned putting much time into it (it still works, but is just cumbersome to use and has some disadvantages). Since then we have focused our efforts on supporting HTML5 and Javascript directly so web games can be build without the need of downloading any extra plugins or runtimes. It also delivers a much cleaner and better implemented web experience. Check it out yourself on our Games site.


We support some low level stuff and can easily add more library support and features we missed (because we or other game teams never needed them), but in the end you are right. There will always be some native Objective-C/C/Java/C++ library on some platform that you might want to use. As you know you can just PInvoke stuff like this on any platform that supports it (iOS is fine, Windows is easy, Android is a little different, but works like Linux, WP7 you are out of luck, no support for PInvoke or anything native). So yes, it is possible to just add a library/dll/etc. in any of your projects and PInvoke it, if you consider that easy enough, but no, it is not fully automated or testable on Windows or as easy to use as the rest of the engine.

The only issue here is that you will most likely want to test the iOS Objective-C library for example and you just cannot do that in Windows because that library only works natively on a device. We often write some small test programs natively on the desired platform first and then just copy the code over to the engine or game. This is probably something everyone wants to do with any complex library. There is also the issue that your PInvoke code must be surrounded by #if IPHONE if you want to compile and execute for non-iOS platforms as well (and you probably need to provide alternatives for other platforms).

This is just one thing that is definitely easier if you write your game natively in Objective-C with XCode on a Mac, so we highly recommend staying away from PInvokes and you will probably never see any part of the public Delta Engine source code having any #if IPHONE or PInvoke code (currently everything is pure C#, no defines, no native code, all ugly native stuff is hidden away in the build system, launcher and converters we build to make your game possible on all platforms).


Yeah, we had a simulator a year ago and will bring it back with lots of optimization tips and cool features like emulating input remotely, rotating, using a Wiimote controller, etc. (all this is currently available in single projects, we just have to bring it all together again). But this feature currently just means that once you build your game for an iPad 1 for example, it will notify you if you do anything wrong. This can be simple things like using too complex Shaders the iPad 1 cannot handle, content that is not really compatible or optimized for iPad, compiler warnings that only happen on this device, use of non-supported language features (will mostly be auto-corrected for you), or too much cpu or gpu usage for that weak device. There can also be fatal errors, for example if you PInvoke a native windows dll, this obviously won't work on the iPad and needs to be fixed.


1) Will it be similar to XNA's one (or the same)? 2) If yes, can I use my own Content Manager? (which I already have and it's far superior to XNA's one)

No, the content system has nothing to do with XNA and it is not like it. You don't even have to use it, you can load everything directly if you want to.

The content system however helps you bringing all files in the best and most optimized formats for each platform and the ContentManager is a great tool to view and organize all content for your game. But again, like any part of the Delta Engine, it is your choice if you want to use it or not.


Not yet, but we will make an example game (simpler version of Arena Wars) soon with the Delta Engine.

The old source code is also very outdated (most of it was written in 2002) and it is hard to get all tools and libraries setup, so it makes more sense to just put together a polished example version for people as a starter-kit for their RTS games.


About Delta Engine all the details can be found on our About page. The Delta Engine is a completely independent company since 2016, but it all started in 2009 with MobileBits GmbH, which was formed from the exDream GmbH. exDream is a developer in Hannover, Germany and has been working with .NET for 8+ years now! The Engine Lead was Benjamin Nitschke, he is the CTO and co-founder of exDream, MobileBits, realis communities and now is the CEO and founder of Delta Engine. He also was a Microsoft DirectX/XNA MVP in 2006-2010, has written the first book on XNA Game Development, and written many .NET games all by himself (e.g. the first commercial .NET game Arena Wars in 2004, the open source Rocket Commander game (2005) and XNA Racing Game (2006) and many more). If you are a .NET developer and want to join our team check out our jobs page.

In 2002-2004 our team developed Arena Wars, the first commercial game that was programmed completely in .NET and C#. This was long before Managed DirectX, XNA or OpenTK was developed. The game's performance was very good, even on slower platforms and has plenty of features (for example replays with voice, webcam data, screen and mouse recording, there is not a single game out having any of these features). We also did other games like Fireburst, Rocket Commander, XNA Racing Game Starter Kit, Arena Wars Reloaded, ZombieParty, SoulCraft, Arena Wars 2 and more.


We don't expect any users of Unity or Unreal to immediately switch over to the Delta Engine once it is out. Those engines have many years of features in them and we are starting from scratch and having a whole different philosophy. However, once you reach the limits of Unity or if you are too annoyed with the complexity of Unreal, you will maybe look around and see there is a different way of doing games with much more control, re-usability and the ease of .NET at all levels, not just scripting in C#, Javascript, UnrealScript, Lua, etc. If you are totally happy with Unity or already are in the middle of your game project, you won't look around for other engines anyway. But if you start a new project and maybe were unhappy about a specific thing in your last project, you will check exactly that feature out and we hope we can provide better support for that and convince some people to use the Delta Engine in the future. 


Benjamin: Currently Xamarin is the best choice for .NET on iOS and Android, ... but horrible for game development, nothing works, nothing is supported.
Henri: Can you elaborate a bit on that? What kind of difficulties you encountered?

We are currently considering between DeltaEngine, or going "naked" with raw MonoTouch/MonoDroid (or staying/resuming with Unity). So a good time for you to make a sales pitch how much time DeltaEngine is going to save us :)

This answer is from early 2011, but still mostly valid:
Well, I have not used Unity for years. We used it in 2009 for a few iPhone games and prototypes and it is still used by our iSkat game, which is played quite a bit still even after all these years. But back then the main problem was getting used to the programming in the Unity Editor (even if doing everything in Visual Studio, to test you have to go back to Unity), which is really a problem if you want to do test driven development. Also the performance was horrible and every upgrade unity got multiple times faster, which is something you will never see in an engine like Unreal or CryEngine (it is already optimized a lot and they can only give you a few percent better in some area).

But Unity3D is far too successful to convince any Unity fan to not use Unity, that is not our audience yet. We don't even have comparable tools in the beta yet and the earliest pitch we should make is at version 1.0 (when we have plenty of tools and more showcase games).

Then there is obviously doing it all by yourself in whatever native language required for each device (Objective-C for iOS, Java for Android, XNA for WP7, PC whatever, etc.), which is an easy pitch because no one likes to do that. We have written several Objective-C games and while it is true that you can get used to it, most .NET developers will never like it and it takes ages to do simple things (at least simple in .NET terms where the framework already provides so much).

So finally there is Xamarin, a great toolkit to allow writing .NET applications on iOS and Android, which is great if you want to write a native iOS application, but you don't like Objective-C and much rather use .NET. However it is still very low level. If you have ever worked with Xamarin (or formerly MonoTouch) you know that you still need a Mac, you still need an iPhone, you still need to learn all the little details about iOS devices, you still need to know the tools on the Mac (XCode, Device Simulators, Profilers, etc.) and worst of all: You still need to learn about all the little problems and issues iOS, Cocoa and whatever frameworks you want to use all have. If you like it close to the metal and you want to code at this level and do everything yourself, it is certainly the way to go. I would even argue that if you really want to write just an iOS game and you don't mind Objective-C you don't even need Xamarin because it won't help you in any way except that it provides the .NET framework.

Now the main issue is something else. We think game developers just want to focus on their game ideas and implement cool shaders, rendering tricks, click some UI together and get to a testable game asap. This is not possible if you start from scratch and solve all the little low level problems one by one. That is exactly the reason engines have been so successful in the last years (especially Unity and Unreal). We try to bring tools to Windows programmers (which is just a bigger audience than any other programmer group) and let them decide what they want to use. We obviously provide some modules to make things work (each platform has Graphics, Input, Multimedia modules and most Physics modules work on all platforms, etc.), but the programmer can decide himself if he wants to change rendering to deferred or not, use this multimedia API or not, focus on just one platform or get them all, use this physics engine or not, etc. There is just not a solution that fits all problems, but if the solution is flexible enough you might still get there much easier than starting from scratch.

Lets take one example to make all my crazy talk above a little more useful and concrete: If you want to write an OpenGL 3D game in .NET for the Android using Xamarin, then you are in a world of trouble. Maybe the framework gets better over the years, but the current state is that you cannot even create or use a Depth-Buffer AT ALL. I posted this 9 months ago as a bug, but it has not been resolved and there are many other issues like it (input crashing, OpenGL is not completely implemented, etc.): https://bugzilla.novell..../show_bug.cgi?id=662079
So obviously the Mono for Android team has no time to fix game programmer problems as most of their customers don't need it, but in order to make a game like SoulCraft work, we needed to fix all that problems and make it as easy as possible for game programmers to just write their game in Windows, then let the Content by converted by the ContentSystem and let BuildSystem handle all the fixes and issues automatically. And whatever features will be added in the future will automatically apply to everyone using our services.

More FAQ and older information can be found in our old wiki.


Internet connection to DeltaEngine.net and API key are required to get started. An internet connection is not required to work with the engine itself, you will only need to be connected to grab content for the first time and if you want to use the online services available through the Editor (like the AppBuilder to create an Android app for example). The Delta Engine is completely open source on Windows, you can modify it to your own use and work completely offline if you want (however no multiplatform functionality is accessible this way and you won't enjoy the rich online services of the Editor).
In order to modify content data in projects, you need to have full access to this project. All DeltaEngine test and sample game projects are read only, so you can view, but not modify content. Use the Project Creator of the Editor to create your own project, there are many templates available to choose from.