Running "behind the scenes actors"

Using Unity, I have a combat "simulator" (right now, just some cubes shooting each other). But, long-term I want to have NPC "league members" that fight other league members. I don't need any of it rendered I just need them to fight each other with the same game mechanics a player (running the game) would use fighting another player or NPC member.

My plan would be to spin up some docker linux images running a "copy" of the battler and then each would pick their own target to fight and record their results (via an API to a centralized game manager).

My question isn't about how to do all that other stuff (I can create the APIs and Docker images no problem), it is about this:

tl;dr:
Can Unity be run in a way where NO input is required and has no rendering with a reasonably small footprint (to run a bunch in docker containers)?

 

Why? Why not pick a winner at random? It won't make any difference to the player how you determine the winner in a fight that they can't see or affect in any way.

 

You apparently can make a server build which will run without rendering.

See here:
https://docs.unity3d.com/2018.3/Documentation/Manual/BuildSettings.html

However, it apparently will be still able to play sounds, and it is not necessarily going to be tiny.

Unity had a "Project tiny" for the purposes of making small footprint builds, but I'm not sure if this is compatible with server build.

What you are trying to do sounds like a cluster sort of simulation and might not be necessarily the right way to do it, although this is debatable.

In your place, I'd consider trying to abstract away combat mechanics, turn them into a C# library. In this case Unity would be used as a rendering API.

 

It will, non-random simulated victory will take longer.

What he's trying to do is a bit similar to X series "in sector" and "out of sector" combat modes.

 

Write all your "battle"-classes in plain C# without Unity. You can put them in a separate DLL and you can use them both in your game and a second, server-application "battle-runner". Simulating a battle without visuals and audio is just number-crunching.

To be perfectly honest, if I would make a battle without the chance that the player can see it or hear it or otherwise would get any information about it other than basic statistics and the winner, I would rather employ the age old trick called weighted random. Obviously the better contenders would get more chance, the weaker ones less. And then you can tweak how better is someone against others...

 

Docker containers for a video game. That's a new one.

 

That's how we are planning to run our dedicated servers. Nothing odd with that

 

Well, the reason is that I want to use the same mechanics (physics, etc) for the NPC as for Human players. I can think of a million easy fake ways to do it, but I want one that if Player A fights NPC B, and Player B has the EXACT same army as NPC B, I'd like the outcomes to match (within reasonable amount of random of course).
And "Docker containers for a video game" is for the scaling ability of Docker to process a lot of combats as need varies - not sure why that is a "new one".

 

That's not a good idea. By that logic you should run battles by having the NPCs watch the game screen, and you'll need DeepMind level hardware to do that. And once you acquire this kind of hardware, the NPCs will UTTERLY destroy the player with no hope for victory.

Spoiler

The goal of a game ultimately is to let the player win at some point. Because if the AI is done seriously the opponent will be superior to the human layer to the point where the game will be no longer fun.

It is also not a good idea to expect to be able to match outcomes, because AI and players should play by different rules. Players are smart, but slow to react. AI is dumb, but inhumanly fast. The game should take this into acount.

 

What you're describing doesn't need like a tenth of the complexity you're thinking about. If your units have stats, use those to determine outcomes. You certainly don't need physics calculations.

weapon_damage * Fire_rate * random_chance_of_hit * total_npcs = incremental_damage_per_(whatever unit you're using for fire rate)

Just loop through that for each side, remove some number of enemies based on that value and the enemy health.

How many "combats" are you thinking of? 10? 100? 1000? 10,000? 100,000? 1,000,000? None of those requires docker or linux. You're overcomplicating things. Not that it can't be done, it's just not meaningful.

 

The general idea was simply to leverage Unity for the physics, the collisions and movement of units. However, you're 100% right that I can simplify the whole combat system to not rely on anything requiring Unity. I just figured it was a quick way to do a lot of the boilerplate stuff - but, if I simply use it as an "outcome reader" then I don't have to use the physics engine for determining anything.
Using Unity as the GAME ENGINE is where I suppose I missed the step. Luckily the thing I want to make can be simplified to not rely on the physics engine or anything terribly complex.

@neginfinity yes, that would be overkill and not the purpose of what I'm thinking. It is basically to "fill up" a series of teams that can fight each other and the players - but not as an RTS or 4x. Additionally, the whole reason for this is that the battles (aside from picking your opponent) have no input.

@EternalAmbiguity to be honest, Docker is really so I have a real-world implementation - not so much that it would really need to be scaled up. With the initial suggestion of just using Unity as the rendering engine and building the combat model in c# straight up, I can accomplish my goal.

Thank you all for the comments so quickly! I haven't worked in Unity long, but the community already seems quick to help. Good stuff!