Jump to content

Distributed Processing Units - Control Units


xNeroX

Recommended Posts

RED HAT SYSTEMS

This topic, sponsored by Red Hat Systems, aims to inform players about the LUA scripting side of the game and clarify the facts.

 

KNOWN ELEMENTS

Propulsion Engines, Fuel Tanks, Cockpit, Navigation Instruments, Doors, Weapons, Batteries, Containers, Accelerometers, Radars, Targeters, Drone Bay, Elevator, Inclinometer (Gyroscope), and last but not least…

 

CONTROLS UNITS / DISTRIBUTED PROCESSING UNITS

Control Units – A control unit is the computer hardware, whereas the DPU (Distributed Processing Unit) is the computer's software. In fact, every element in the game will have a built-in DPU. The difference between control units and other elements is that the control units exist specifically to run player-customized DPU's, whilst the DPU's embedded in other elements are not customizable.

 

DPU's will be distributed (sold, copied, transferred, etc) in black boxes. Think of the black box as a USB Memory Stick. Only a single black box can be inserted into a control unit at any one time, however a construct (ship, car, boat, factory, etc) can have many control units and therefore many black boxes. The black box is therefore simply a transport mechanism for the DPU. More on black boxes later.

 

Each DPU will be capable of emitting events (standard pre-defined events written by the devs and also player-defined events written in LUA) and exposing executable functions (again, predefined + custom). The DPU will also have a collection of event handlers (again, predefined + custom: you get the idea). An event handler simply listens out for events, and then executes a function if a player-defined expression evaluates as true.

 

Each DPU has multiple slots where other elements can be plugged into (Think of USB Ports).

 

KNOWN EVENTS (EXAMPLES)

self.radar1.enemyAt(x,y,z)

 

KNOWN FUNCTIONS (EXAMPLES)

self.inclinometer2.getRoll()

self.Inclinometer4.getPitch()

self.engine1.setPower(100)

self.weapon7.fire()

 

In the example events and functions above, “self” is simply a Lua keyword that implies the code is referring to its own scope. “radar1”, “weapon7”, etc are the names of the slot that is emitting the event or is being targeted to execute a function. “getRoll()” is an example of a function being invoked (safe to assume it will return a numeric value with roll angle).

 

SYSTEM DPU

The system DPU is rather special. It handles user input (emit event when a key is pressed) and also controls the flow of procedural code (as opposed to event driven) via the use of timers. I.E you could call system.setTimer(0.1) and provide a function that will be invoked every 100 milliseconds. Another awesome feature of the system API – Customizable GUI! That's right, via calls to system you can customize the games GUI.

 

BLACK BOX/COMPONENT DPU

A Component DPU is an element that you, as a programmer, will be selling to other players. It will abstract the functionality of your custom DPU into what can be seen as a compiled library. The end user will be able to consume your functions and events without seeing the underlying code. If the end-user is another programmer then they can use your Component DPU as a module to write their own Component DPU which requires your Component DPU in order to work. If the end-user is not a developer they can either drag and drop the required functionality via a simple UI, or they can make use of an auto-configure system (Think Plug and Play).

 

SUMMARY

What the devs have done here is give us access to the very tools they themselves use to build the game. When you use a Propulsion Engine, its functionality was written by the devs in the same way a player might customize a DPU. The Propulsion Engine has its own pre-defined fully functional DPU inside it. By introducing the concept of Control Units we as players can fully mod the game, from within the game. If we don't like the way the Propulsion Engine handles, that's fine, we can just overide the behaviour with our own code. The same for almost every element in the game. The devs has basicly created an in-game IoT (Internet-of-Things). This system literally redefines Emergent Gameplay, in fact it laughs in the face of Emergent Gameplay. Nothing else comes close.

 

Intrigued? Love to code, or hungry to learn? Join the most advanced organization in Dual Universe. Red Hat Systems needs you!

Link to comment
Share on other sites

I like the post, very informative. But why, do you list drone bay and elevators as known. I don't remember anything about them in the devblogs or interviews, if you remember where you got that could you drop a link so I can check it out please.

Link to comment
Share on other sites

I like the post, very informative. But why, do you list drone bay and elevators as known. I don't remember anything about them in the devblogs or interviews, if you remember where you got that could you drop a link so I can check it out please.

Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.

 

first paragraph of the dev blog on scripting...... https://board.dualthegame.com/index.php?/topic/314-devblog-lua-scripting-and-distributed-processing-units-dpus/?hl=drone

Link to comment
Share on other sites

Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.

 

first paragraph of the dev blog on scripting...... https://board.dualthegame.com/index.php?/topic/314-devblog-lua-scripting-and-distributed-processing-units-dpus/?hl=dron

. . . oh.

Link to comment
Share on other sites

. . . oh.

Also, the Core Units go down to 25cm voxel size. That screams "make drones with these babies" to me, cause JC made his ship on the video with a 1cubic meter Core Unit :P

 

 

Either a drone, or a glider, which is equally cool. 

Link to comment
Share on other sites

RED HAT SYSTEMS

This topic, sponsored by Red Hat Systems, aims to inform players about the LUA scripting side of the game and clarify the facts.

 

KNOWN ELEMENTS

Propulsion Engines, Fuel Tanks, Cockpit, Navigation Instruments, Doors, Weapons, Batteries, Containers, Accelerometers, Radars, Targeters, Drone Bay, Elevator, Inclinometer (Gyroscope), and last but not least…

 

CONTROLS UNITS / DISTRIBUTED PROCESSING UNITS

Control Units – A control unit is the computer hardware, whereas the DPU (Distributed Processing Unit) is the computer's software. In fact, every element in the game will have a built-in DPU. The difference between control units and other elements is that the control units exist specifically to run player-customized DPU's, whilst the DPU's embedded in other elements are not customizable.

 

DPU's will be distributed (sold, copied, transferred, etc) in black boxes. Think of the black box as a USB Memory Stick. Only a single black box can be inserted into a control unit at any one time, however a construct (ship, car, boat, factory, etc) can have many control units and therefore many black boxes. The black box is therefore simply a transport mechanism for the DPU. More on black boxes later.

 

Each DPU will be capable of emitting events (standard pre-defined events written by the devs and also player-defined events written in LUA) and exposing executable functions (again, predefined + custom). The DPU will also have a collection of event handlers (again, predefined + custom: you get the idea). An event handler simply listens out for events, and then executes a function if a player-defined expression evaluates as true.

 

Each DPU has multiple slots where other elements can be plugged into (Think of USB Ports).

 

KNOWN EVENTS (EXAMPLES)

self.radar1.enemyAt(x,y,z)

 

KNOWN FUNCTIONS (EXAMPLES)

self.inclinometer2.getRoll()

self.Inclinometer4.getPitch()

self.engine1.setPower(100)

self.weapon7.fire()

 

In the example events and functions above, “self” is simply a Lua keyword that implies the code is referring to its own scope. “radar1”, “weapon7”, etc are the names of the slot that is emitting the event or is being targeted to execute a function. “getRoll()” is an example of a function being invoked (safe to assume it will return a numeric value with roll angle).

 

SYSTEM DPU

The system DPU is rather special. It handles user input (emit event when a key is pressed) and also controls the flow of procedural code (as opposed to event driven) via the use of timers. I.E you could call system.setTimer(0.1) and provide a function that will be invoked every 100 milliseconds. Another awesome feature of the system API – Customizable GUI! That's right, via calls to system you can customize the games GUI.

 

BLACK BOX/COMPONENT DPU

A Component DPU is an element that you, as a programmer, will be selling to other players. It will abstract the functionality of your custom DPU into what can be seen as a compiled library. The end user will be able to consume your functions and events without seeing the underlying code. If the end-user is another programmer then they can use your Component DPU as a module to write their own Component DPU which requires your Component DPU in order to work. If the end-user is not a developer they can either drag and drop the required functionality via a simple UI, or they can make use of an auto-configure system (Think Plug and Play).

 

SUMMARY

What the devs have done here is give us access to the very tools they themselves use to build the game. When you use a Propulsion Engine, its functionality was written by the devs in the same way a player might customize a DPU. The Propulsion Engine has its own pre-defined fully functional DPU inside it. By introducing the concept of Control Units we as players can fully mod the game, from within the game. If we don't like the way the Propulsion Engine handles, that's fine, we can just overide the behaviour with our own code. The same for almost every element in the game. The devs has basicly created an in-game IoT (Internet-of-Things). This system literally redefines Emergent Gameplay, in fact it laughs in the face of Emergent Gameplay. Nothing else comes close.

 

Intrigued? Love to code, or hungry to learn? Join the most advanced organization in Dual Universe. Red Hat Systems needs you!

 

Any chance I could convince you to turn this into a page on the wiki?  (or could I adapt this into one)

Link to comment
Share on other sites

Very interesting ! and intrigued !

 

Now how difficult would it be for a non programmer to dwelve into this subject ?

Not very, there is an auto-programmer that links all the elements together for you and NQ are proving some basic scripts to work with. It doesn't take much to delve in and mess about, if you break it then just start again and learn from your mistakes!

 

There are loads of people on here that are willing to help out with scripting in-game once we get hands onso don't worry :)

Link to comment
Share on other sites

Not very, there is an auto-programmer that links all the elements together for you and NQ are proving some basic scripts to work with. It doesn't take much to delve in and mess about, if you break it then just start again and learn from your mistakes!

 

There are loads of people on here that are willing to help out with scripting in-game once we get hands onso don't worry :)

 

Perfect then ! looking forward to give it a try.

Link to comment
Share on other sites

Lua is something I plan on learning. Finally, I can learn code while doing something I enjoy. (Thanks to Dual Universe) In the past, I've always gotten bored and left it be because it was just so damn tedious to learn code on your own.

Link to comment
Share on other sites

I'm as excited about this as the next person, but doesn't this open up the opportunity for exploits/hacks? What about self-replicating scenarios? How is all of this going to be so open, yet still controlled in a way that it doesn't get out of hand? 

Link to comment
Share on other sites

Self replication will first be VERY difficult and time consuming, but we all know that is speeds up exponentially.

 

If scripts were executed "server side", you could theoretically create a self replicating robot that would fill the entire server just like a computer worm.  In fact, you could just write a worm and have it execute on the server.

 

However, it's already been confirmed that scripts will execute "client side".  Given the identical scenario, the player would most likely lock up their computer, and kill their bandwidth (especially since their upload speeds are usually slower than their download speeds).  The scripts would also ONLY execute while the person is playing the game.

 

My guess is there will be safeguards in place to prevent this type of abuse entirely.

Link to comment
Share on other sites

But again this brings us around the the large scale ship debate.

 

If the scripts stop running when a player logs out then it means that anything I've programmed on a large ship with loads of players on board will stop working straight away and leave them all stuck on a lifeless construct.

 

How do you define a ship on this scale to continue running, to say a drone that stops running when when you log out?

Link to comment
Share on other sites

For clarification. Scripts RESIDE in the construct and EXECUTE on the client.

 

That multi-player ship doesn't disappear when you log off. Think of each control unit as a separate machine. The pilot executes the piloting script on their client while the weapons officer executes weapons scripts on their client

Link to comment
Share on other sites

I never said the ship disappears.

 

The script might still be there, but if the client isn't online to excecute it then it's lifeless, and if no one else on that ship has permission to use that construct then you are stuck.

 

If you say that the client just sends a command (such as 'Forward 10% Thrusters') to the DPU then logs out, but the ship keeps moving forward then the script isn't being run on the client said then.

 

If the script still runs when the client logs out then you have the situation when you can make drones that run by then selves and/or self replicate as much as they want.

Link to comment
Share on other sites

Your Right!

 

If the captain doesn't give rights to other users, and logs out, or drops connection, the multiplayer ship would be adrift (with players on it).  But that problem is a lack of foresight by the captain.  He SHOULD have given permission to key players for just such an emergency.  But even on that ship thats adrift, if a player was operating the weapons console, they should still be able to fire because the weapons console script was executing on a players client that was still logged in.

 

Drones wont continue to function unless their control is taken over by another player.

Link to comment
Share on other sites

In what way does the running of the client side script jump from <player 1> to <player 2> to run when <player 1> drops from the game?

This goes for ships/drones/auto-machines and everything in between really, the basics of how it all runs and works together. Once we fully know how all this works properly (no more guess work) then things like the self-replicating drones can be brought up again, but at the moment we are just working with snippets of info.

 

EDIT: Sorry, kinda de-railed the topic a little  :P

Link to comment
Share on other sites

There isn't just ONE script per ship.

 

Think of each station as a kiosk or ATM machine.  Each machine is capable of performing some function.   Weapons, piloting, etc..

 

There doesn't need to be communication between the machines for them to work.  Each machine can function on separate clients.

 

Now,

 

There probably are times when communications do need to take place between machines.

 

Maybe make a third "Communications" machine to govern that.

 

Of course, a LOT of this, is dependent upon the ship designer.  He needs to have some foresight to build the ship so that there's some redundancy in place.  There are definitely unknown hurdles, but a good programmer will work with what he's given.

Link to comment
Share on other sites

In what way does the running of the client side script jump from <player 1> to <player 2> to run when <player 1> drops from the game?

Easy,

 

Weapons officer Smith, notices nobody is at the helm.

 

He leaves his station, and takes over the helm.  Now, the weapons script is not working, and the piloting script starts working on <player 2>

Link to comment
Share on other sites

You're not quite getting the point i'm trying to put across though. In the situation you mentioned above this is kinda correct, but for simplicity lets just assume there is only one DPU and one script (a flight script) being run on this huge spaceship by <Player 1>. There is 1 other players on this ship (for example, it doesn't really matter how many).

 

- The ship is moving at 100% speed and being controlled by <Player 1> with the script being executed on <Player 1's> client.

- The flight script is continuously updating the speed to 100% speed to keep the ship moving forward.

- <Player 1's> client crashes and the the script which is being executed locally stops running and doesn't update the ships speed anymore.

- The ship would stop dead in it's tracks and be lifeless.

- <Player 2> could pick up the pilot's chair and restart the whole process of setting the speed to 100% to get the spaceship moving again.

- <Player 1> logs back in and wants the pilots chair back.

- <Player 2> would need to cancel all operation of the flight script, which would stop the ship dead in it's tracks again, and let <player 1> start the whole process again.

 

With that, how is the running of the flight script transferred from <Player 1> to <Player 2> without it stopping? This means no interruption to the running of the script or immersion in game?

 

If there is a way to keep the script alive even after the client has crashed/disconnected then this will mean we can create drones, and in turn self replicating machines/drones.

 

No amount of foresight or LUA knowledge will help you in this scenario, unless there is something the devs are implementing to keep the script running on at least 2 players clients at the same time. Again, this is all guess work.

Link to comment
Share on other sites

I see where you're coming from.

 

This discussion has now gone to a level where the development would need to get involved. They would need to discuss how much work is done client side.

 

If you'd like to know good game programming practices, I'd recommend visiting gafferongames.com. on that site, Glenn Fiedler explains that ONLY player input should be accepted from the client. NOT positioning or damage data.

 

Now I don't know how much of that is handled by the DU client.

 

The client may just report back the ships vector and it's linear and rotational acceleration. But this is pure speculation.

 

If player 1 were to disconnect given the above scenario, the ship would continue to travel in the same direction and speed. It wouldn't just immediately stop.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...