How hard is to move from Unity3d to custom built game/engine.

Well, as long as it's purely for the sake of expanding your mind... I'll condone it, but only to a limited degree.

 

Hmm very interesting. Maybe he is not using colliders nor Rigidbody. But yes I agree that if one does it wisely, he can have more objects in scene at once. (But not more than in custom built engine specific for that purpose )

 

Sorry didn`t find Dev Blog how they dealt with the Performance. Could you point me to link please?

 

I asked him about it here http://www.arcengames.com/forums/index.php?topic=14138.0 or reach out and ask the developers directly.

 

@Wrymnn: I think the most important hint in this thread is the following, read it again:

================================

Thanks, nice link.
But the following is most often a bad idea:

Trading a single "if" for a single multiply is a bad deal normally.

 

I've done a quick test, sorry can't resist these things and I can get 4000 simulated units in 3d space that fight and move @30fps on my PC.

Uses game objects for units with sphere colliders, rigidbodys (to allow units to scan for nearby units) and sprites to allow me to see what is happening and debug.

The combat system is a simple d20 attack/defend with health.

But if you abstract your game objects to c# classes, use a system or node based combat space (like the example) so no range checks needed as any in system units can attack others in that system.

Make it multi-threading as the battles will be taking place regardless of the main Unity thread. Then relegate Unity to a display/camera system showing battles in the current system or the system view.

Even if you don't use Unity you will probably need to go this route or abstract further and use a server client system. With a server / client the core simulation would run on a server and a client would allow people to connect to and view/interact with the battles.

The benefit of a server / client setup is you could take it multi-player.

NB it is possible to build and run a Unity version of your game in a format suitable for a server -batchmode http://docs.unity3d.com/Manual/CommandLineArguments.html

 

There is no physics there at all. It is all just simple math and rendering optimization. For all intents and purposes it is a simulation, as the user is not affecting the battle directly. That example is fairly easy to replicate, it's deterministic (essentially). I built something similar in flash a couple of years back (leveraging stage3d). The graphics were more complex than that example and were all animated. But I was able to have a 10,000+ animated tanks on screen zooming around firing rocket salvos at each other for a total of ~50k animated objects running at 60fps in Flash. Might not hit that threshold on a device, but easily doable stand alone or in browser. Unity should be able hit that without much effort.

 

Maybe you should consider the Mantle powered Nitrous Engine 10,000+ 3d units and bullets/shields in 3d?

WTF No way! LOL you are going to have to show me a video of this now YouTube has 60fps now so come on. I can't imagine flash handling those numbers and Unity 4.x can only hit about 1000-2000 units even in standalone.

 

Sorry if I'm coming in at the tail end here, but have you tried ditching the ridgid bodies for your own basic physics? And have you tried tweaking the FixedUpdate settings under the time settings?

 

GPU. (about half that in <fp10 with blitting). Unity can do way over 2k units. (assuming batching and not physics). Its all about optimization.

 

There is a common misconception that C++ will run faster.. because its C++, but this is not always true. C++ wins in scalability, but an intelligently written c+ program will do the same.

Really anything you want to do in c++ can be done in unity. There is always a way. You could even run assembly in unity if you know the path. For any features that you think you need c++ for, you may be able to compile into an external DLL and reference through c#.

The truth is, if collisions are taking too much, you can always write your own collision logic. You do not need to use the vanilla unity tools.

If you decide to take on the task of writing your own engine, you will need a lot of help and resources depending on the complexity.

I woudl say it will be a great learning experience but will not be all that practical. You may want to start with an opensource engine and branch off of that for starters.

 

Will surely try to put TimeStamp to 0.33 isntead of 0.2.

 

I cannot even believe you would have 50 000 static objects with nothing in unity. Even when I try to copy 2000 objects with ctrl+D, it will lag for 10 seconds and them moving 2000 units in batch is lagging as hell in Editor

 

@zombiegorilla would love to know more, do you have a blog or links to info on how to do this?

Well removed the physics from my test run and can get 10,000 "units" displayed as sprites in Unity about @60fps. The targeting enemies system just selects at random so no need for physics based detection.

Top Number Unit Counter, Bottom FPS http://dl.dropboxusercontent.com/u/19148487/SimulatedBattleTest/webBattleTest.html

 

Hi Wrymann,
I'm also very enthusiastic from the game "Galaxial" so i started thinking how this game works... i looked in the dev-log on the Galaxial Website and saw that he is using C++ and OpenGL and also "Parallel Patterns Library".

I just started programming and watching tutorials how to write games in OpenGL but the point is... its not the Unity Engine that will make your game slow, it's your Code!

I was working to on a similar Project but with the Unity Engine... with my Code i can aktually Spawn 5000 AI's and Projectile's with 60 FPS! Watch my Video and tell me what you think

-lg Alex

 

You're doing it wrong. You are creating thousands of GameObjects. What you need to do is make a single GameObject control batches of enemies. Essentially you would be creating something akin to a particle system.

 

What are you doing? Implementing the entire OpenGL header?

You can get all of what you say done in two weeks. You can even get a hack job of what you say done in a day or two.

 

After reading the opening post and then the entire thread I have surmised that the OP really has no clue what he's doing, what he wants, why he wants it. His replies to very important questions show his absolute lack of experience and technical prowess.

C++ is not that bad. Using it effectively by utilising its features is what defines a c++ coder from a person that starts threads like these.

Quick Quote.......

 

Exactly. Mass objects are a different approach, very stripped down and deterministic, usually a routine controlling them all (or batches), virtually no functionality on their own. For the Flash stuff, it was simply done with a custom renderer, what appeared to be many thousands of objects on screen was really just one bitmap with everything calculated outside the render loop. It's all about smoke and mirrors.

 

Wow this was amazing xD but as you can see even 7000 objects makes 17 fps.
I found out that performance in editor when not having your game compiled makes the fps 3x slower.
But the guy in galaxial is using multithreading. So he can have those 14k ships in many threads. That we cannot do in unity.

 

Within games like these where you have a lot of individual units, it is best to think of GameObjects not as individual objects but as object managers. As was said earlier you will need to handle rendering, updating, and collision for your ships in batches with each batch controlled by a single GameObject.

While some aspects of Unity are not multithreading safe, you can still multithread the process of updating and collision detecting the ships so long as you use your own logic and aren't relying on Unity's.

This is no different than how you would do it with a custom engine. Switching engines won't magically solve anything.

 

AI War does tens of thousands of units in Unity.

http://www.rockpapershotgun.com/2010/10/27/the-a-i-war-update-to-end-all-updates/

No real need to do an entire engine from scratch if all you want is high unit counts.

 

Okay so after a lot of trying and playing, I have managed to get 4000 SpaceShips with 40 - 300fps stable moving to mouse direction. So I click on ground and all 4k ships are going to that position.

This test was calculated in Build & Run stand-alone game not via Play option in unity!

What I have discovered:
- Disabling any type of collider on all of them increases fps by 20-30fps
- Moving them by transform.translate reduced fps to 5fps. So only way how to move a lot of objects in Unity is via rigidbody.
- Disabling trail renderer increases fps by maybe 10fps on 4000 gameobjects.
- And ofcourse, ships has to check for position every 0.3 - 0.5seconds so they stop if they are at given position.

If there would be way to Eliminate this stuff, there would be possibility to have moving 10k + gameObjects in unity with 50+ fps.
- Not have Collider (How would we then check for bullet collision or selecting given spaceship)
- Reduce check for distance (But then how do we check if we are at given position to stop)

 

Why do you need the rigidbodies if you'be removed their colliders and you're moving away from physics?

 

You cannot Remove colliders since there is no way how to detect bullet collision or if mouse is over that sprite. (Only by getting position of object , comparing to mouse position etc.)

And I don`t have to have rigidbody ofc, but then Collision won`t work, and I cannot move the object since transform.Translate drops fps to 5 when having A lot of objects.

 

When dealing with that many objects, you don't really need to use collision. You can pre-determine so it is just a matter of timing and math.

 

True, I can get the distance to Bullet target, and if I do simple math with bullet speed I can get estimate that when the bullet could hit the target.
Though Bullets will have to follow target, so they dont deal damage even if they dont hit any ship.

 

You could make the bullets fairly fast, or just lerp to follow. Though if look on many of the mass ship type games, usually they don't get too complex, bullets often will only hit their targets, and pass through other objects. Some of the example videos in this thread display that.

Of course you could always just obscure it by using big flashes, fuzzy bullets and particle fx to dazzle the player so they don't notice the minor details.