Recent content by hakjimmy

SupaNinjaMan said:

Python:

("cf_use_teleport_door", # server: handle agents using a door which teleports to another linked door
[
    # Script Input Variable Set-up
    (store_script_param, ":agent_id", 1), # must be valid
    (store_script_param, ":instance_id", 2), # must be valid
    (store_script_param, ":x_offset", 3),
    (store_script_param, ":y_offset", 4), # position offset relative to the linked door that the agent is moved to
    (store_script_param, ":z_offset", 5),
    (store_script_param, ":is_pickable", 6),

    # Variable Set-up
 
    (scene_prop_get_slot, ":linked_door_instance_id", ":instance_id", slot_scene_prop_linked_scene_prop),
    (gt, ":linked_door_instance_id", 0),        # This is a check to prevent warning messages
    (agent_get_player_id, ":player_id", ":agent_id"),    # This is a multiplayer operation, pulls the player's id based on their agent's id
    (player_is_active, ":player_id"),                    # Makes sure the player_id is valid by making sure the player is active and not like the server or absent
    (player_get_slot, ":player_faction_id", ":player_id", slot_player_faction_id),    # This stores the referenced player's slot inside the first local var, in this case it looks at the slot named slot_player_faction_id and stores it inside of ":player_faction_id"
    (call_script, "script_scene_prop_get_owning_faction", ":instance_id"),    # Calls a script and passes it the prop instance id, assumedly it outputs the prop faction to reg0
    (assign, ":faction_id", reg0),    # Storing a reg value into a local var to make it readable
    (assign, ":fail", 0),        # this, my friend, is a flow control variable, commonly used to prematurely break scripts if the desired result isn't matched.
 
    # This try block is the bulk of the work, basically it's a if-else statement
    # Best way to read it is, if the first flow-statement is met, then the script
    # will not check other blocks, but if it is not met, it skips to the next (else_try),
    # block. This is where the branching nature of scripts is made.
 
    (try_begin),
        (eq, ":faction_id", "fac_commoners"), # If TRUE, prop faction = common
        # Don't do anything, but go ahead and skip the rest as we found our TRUE statement
    (else_try),
        (eq, ":faction_id", ":player_faction_id"),    #If TRUE, prop faction = player faction
        # The above was true, so no longer go to the next else_try. But ALSO. . .
        (player_slot_eq, ":player_id", slot_player_has_faction_door_key, 1), #If True, player_id slot slot_player_has_faction_door_key = 1
        # So this second statement does not effect the status of continuining within the try_block
        # but it prevents this next block from firing.
        (try_begin),    # This block actually doesn't need to be a try_block, they could have done without it. For readability, I do the same thing though.
            (scene_prop_slot_eq, ":instance_id", slot_scene_prop_unlocked, 1), # If Locked
            (scene_prop_set_slot, ":instance_id", slot_scene_prop_unlocked, 0),    # Unlock
            (scene_prop_set_slot, ":linked_door_instance_id", slot_scene_prop_unlocked, 0), # Unlock here, too
            (agent_play_sound, ":agent_id", "snd_lock"),    # Play a sound at the agent, I don't do MP but I assume sounds are synced with the server and nearby players can hear it.
        (try_end),
    (else_try),
        (scene_prop_slot_eq, ":instance_id", slot_scene_prop_unlocked, 1),    # This should really be the first one thing inside the try_block since there's no reason to check anything else if the door is already unlocked.
    (else_try),
        (assign, reg0, 0),        # I am assuming that script_cf_agent_pick_lock uses reg0 to determine lockpick chance.
        (eq, ":is_pickable", 1),    # I did not see this get set earlier, so, this should always fail. Unless script_scene_prop_get_owning_faction set it, which seems outside the scope of the script based on name.
        (call_script, "script_cf_agent_pick_lock", ":agent_id", 100),    # But, if the above is somehow true, run this script. Assumedly it rolls for a chance to pick the lock.
        (scene_prop_set_slot, ":instance_id", slot_scene_prop_unlocked, 1), # If successful, Unlock
        (scene_prop_set_slot, ":linked_door_instance_id", slot_scene_prop_unlocked, 1), # Unlock here, too.
        # Not gonna lie, the above block seems like it's not fully finished.
    (else_try),
        # No flow control statements here eq|neq|gt|lt|etc, which means this will always be fired if an above block didn't find itself being used
        (assign, ":fail", 1),    # sets fail to true
        (gt, reg0, 0),    # And reg0 is a positive number, which may be possible, sure.
        # DONT DO ANYTHING.
        # for some reason
        # It seems as though this is meant to interact with script_cf_agent_pick_lock or the faction_id from earlier? But why not call faction_id then?
        # Let's assume it's seeing if the faction of the prop is a positive number, and if so, keep the message of the next block from firing.
        # Though, if that's the case, why not make them the same else_try block?
    (else_try),
        # No flow control statements here eq|neq|gt|lt|etc, which means this will always be fired if an above block didn't find itself being used
        (multiplayer_send_3_int_to_player, ":player_id", server_event_preset_message, "str_door_locked_by_s1", preset_message_faction|preset_message_fail_sound, ":faction_id"),
        # Reads as if it tells the player the door was locked, and maybe by which faction.
    (try_end),
 
    (eq, ":fail", 0),    # if the fail local var didn't get set to 1 by the second to last else_try block
    (prop_instance_get_position, pos1, ":linked_door_instance_id"),
    (position_move_x, pos1, ":x_offset"),
    (position_move_y, pos1, ":y_offset"),
    (position_move_z, pos1, ":z_offset"),
    (agent_set_position, ":agent_id", pos1), # Teleport the player agent.
]),

I added comments and reformatted the tabs to help you make sense of it.

To prevent a situation where you get instead of:x or lose your tabs again, use [CODE=python][/CODE] tags.

Click to expand...

(else_try),
        (assign, reg0, 0),        # I am assuming that script_cf_agent_pick_lock uses reg0 to determine lockpick chance.
        (eq, ":is_pickable", 1),    # I did not see this get set earlier, so, this should always fail. Unless script_scene_prop_get_owning_faction set it, which seems outside the scope of the script based on name.
        (call_script, "script_cf_agent_pick_lock", ":agent_id", 100),    # But, if the above is somehow true, run this script. Assumedly it rolls for a chance to pick the lock.
        (scene_prop_set_slot, ":instance_id", slot_scene_prop_unlocked, 1), # If successful, Unlock
        (scene_prop_set_slot, ":linked_door_instance_id", slot_scene_prop_unlocked, 1), # Unlock here, too.
        # Not gonna lie, the above block seems like it's not fully finished.
    (else_try),
        # No flow control statements here eq|neq|gt|lt|etc, which means this will always be fired if an above block didn't find itself being used
        (assign, ":fail", 1),    # sets fail to true
        (gt, reg0, 0),    # And reg0 is a positive number, which may be possible, sure.
        # DONT DO ANYTHING.
        # for some reason
        # It seems as though this is meant to interact with script_cf_agent_pick_lock or the faction_id from earlier? But why not call faction_id then?
        # Let's assume it's seeing if the faction of the prop is a positive number, and if so, keep the message of the next block from firing.
        # Though, if that's the case, why not make them the same else_try block?
    (else_try),
        # No flow control statements here eq|neq|gt|lt|etc, which means this will always be fired if an above block didn't find itself being used
        (multiplayer_send_3_int_to_player, ":player_id", server_event_preset_message, "str_door_locked_by_s1", preset_message_faction|preset_message_fail_sound, ":faction_id"),
        # Reads as if it tells the player the door was locked, and maybe by which faction.
    (try_end),

Captain Obvious said:

Well atm it is only 100, but I think overtime it will meet 200 and probably surpass that. I'd love to see 400-600 size servers with Persistent maps

Click to expand...

shatti said:

dude even if it somehow managed to do it, ur GPU would not handle it
i tried my 2080 ti, i7 9700k in warband
on ultra settings, 2k resulotion, custom match 200 vs 200
it kept lagging as hell until a great portion of men died
400 men !!!!!
u want 1000 in bannerlord (a way more demanding graphics game) !!!!!

i would say u could hit 500 men mark with the latest titan gpu, and i9 9900k on 1920 resolution & medium settings maybe
no gpu yet could handle 1000 npc, not even in warband

they included 1000 men option so we could do it in 2030, not for now

Click to expand...

Gabriel Gambetta is Tech Lead/Manager of the SpatialOS Community team at Improbable.

Imagine building a game world—not one based on scripted events, but on millions of individually simulated entities with rich behaviour. A fully physical, living, breathing simulated reality based on simple rules. A massive world with no artificial boundaries and where nothing is faked. An environment where thousands of players can interact simultaneously, where their actions have long-lasting consequences and create emergent storylines.

That is precisely what Bossa Studios is building with Unity and SpatialOS.

Bossa’s impossible dream
An ambitious idea came up during an internal game jam organised by London-based game developer Bossa Studios in 2014: build a beautiful world with magnificent vistas and vast landscapes players could explore, interacting with creatures with realistic lifecycles and a fully dynamic ecosystem that would respond to their actions.

Players would chop down trees and carve out iron deposits, and craft parts they could use to build floating airships, which then would get involved in massive battles involving cannonball fire and boarding parties. And on top of that, it would be a single, unsharded, massive world where every player would be at the same time.



A rough playable prototype was made during the game jam, using the popular Unity game engine. However, expanding it into a full-blown, always-on online game—thousands of players in a single unsharded, persistent, physically simulated world—would have been too ambitious even for the largest studios, let alone a small one.

The technology to build and manage such a game just didn’t exist. So the idea had to be shelved.

The need for a new paradigm
Online games typically use a client-server model—a single massive server receives inputs from the clients, updates the simulated world, and sends updates back to the clients. This imposes a hard limit on the richness of the world: limited hardware resources need to be split between every entity that needs to be simulated.

This necessarily leads to trade-offs. For example, you can choose between realistic physics in a tiny map with a handful of players, or simplified physics in a big map with hundreds of players, but not both. And having millions of entities with complex behaviors is out of the question, resulting in the “theme park” feeling of many MMOs.

In summary, devs are forced to make creative trade-offs and compromise on their game’s design for purely technical limitations. Clearly we need a different way to make games.

The SpatialOS approach is an evolution of the well-known Entity-Component-System architecture. Everything in the world (players, rocks, creatures) is an entity, the core building block of a simulation. Entities are made of components, which describe their different aspects (Health, Physical) and can be combined freely.

applications

Entities components are simulated by workers, a swarm of micro-services dynamically allocated to cope with the changing workload of the simulation. These workers can be game engines such as Unity.

By using a dynamic swarm of workers instead of a single server, SpatialOS lets you build worlds of arbitrary scale and complexity. Each individual entity can have as much compute power as necessary to make it as interesting as you want, without a trade-off dictated by technology limitations, and you can have millions of them.

Building a game client is equally simple; you build it using the game engines you know and love. For example, you can use Unity to visualise the state of the simulation on the player’s machine. In fact, since the game client is just a window into a single ongoing, living world, you can build multiple devices—PC/console, mobile, VR headset—that interact with it simultaneously.

Create your game by defining entities and components and writing client-side visualization code, test it on your local machine with the SpatialOS SDK, and then deploy it to the cloud, making it instantly playable for anyone with a link to the game—potentially thousands of players in the same place at the same time. And you don’t need to write a single line of networking code!

While single-player games are “released”, game worlds are “launched”; they need to be continuously monitored and maintained. SpatialOS runs your game world in a public cloud provider such as GCE, and provides web-based tools to manage and monitor it.

The rest is handled for you – you don’t have to deal with capacity planning, load balancing, fault tolerance or cluster monitoring, which would otherwise require significant resources and effort.

Worlds Adrift
A team of five developers at Bossa Studios decided to port their ambitious prototype to SpatialOS and Unity—and in a short time they managed to build Worlds Adrift, a game world that continues to be interesting independently of players, where you can fully immerse yourself and explore at your leisure.

In Worlds Adrift, thousands of simultaneous players can interact with each other in a massive world that feels real. They can chop down trees, harvest the wood to build a ship, and then fly the ship from one end of the world to the other without running into a single artificial boundary or loading screen.

Ship craft and takeoff

If the ship succumbs to cannonball fire while fighting another group of players, its pieces will fall to the ground and stay there forever—or at least until another player salvages them, even if it’s two (real-life) years later.

Worlds Adrift airship blowing up

Or they can find the perfect vantage point to watch flocks of marvelous creatures going about their daily lives, feeding, fighting and reproducing.




And when the sun sets, they can craft musical instruments, sit around a campfire, and share their latest adventures with each other.

Campfire timelapse

None of this is faked. There are no scripted events; players create stories by interacting with each other and with the world, a world that feels real due to the complex behaviors that emerge from the interactions of thousands of players and millions of individually simulated entities with detailed AI, such as a fully functional ecosystem. Everything is persistent, so player actions have long-lasting consequences, creating truly meaningful experiences. We have collected some of them here.


In one Worlds Adrift scaling test, we simulated a game world of 25,600 square kilometres—larger than the real-life surface area of Wales—inhabited by four million entities. This required 49 logic workers and 625 Unity engines collaboratively simulating the world’s physics (a hard problem on its own).

At the peak of this playtest, thousands of players were roaming around the islands, harvesting materials, building ships, and engaging in exciting yet completely unscripted battles.

Do it yourself!
A small team can quickly build a commercial MMO such as Worlds Adrift, set in a world of a scale, complexity and level of detail never attempted before, where thousands of players can interact simultaneously, with no more effort than it takes to build a single-player game.

We can’t wait to see what new kind of games become possible when scale and complexity are not an issue. 10,000 players in a single massive FPS battle? Incredibly realistic worlds on your mobile phone? The kind of immersive experiences VR deserves? Sign up for SpatialOS and decide yourself.

Update – we have announced new Unreal and Unity game developer kits (GDKs) as improved versions of our SDKs. Find out more about the Unity GDK and Unreal GDK.

Click to expand...