Block Party (Terrain Ex. Pg.124 - 2Million Blocks)

Author Topic: Block Party (Terrain Ex. Pg.124 - 2Million Blocks)  (Read 237405 times)

snip
I love it, perhaps multiple processor and effecter nodes can be strung together as well, based on subsequent detector nodes that are used.
I agree, it is a simplistic system that people will be able to grasp pretty easy and it is pretty dynamic in nature, I would suggest having a more simplistic "Basic" mode like this, and a more complex but dynamic "Advanced" mode.

I imagine a node system more akin to the one Blender has. One where there are various types of nodes again, each one with a little circle on each side, these would act as plugs and outlets, color coded to demonstrate what information can and can't be passed to various inputs. I'm working out what the system would have, I'll show off an example when i have one.


I wasn't aware it was supposed to be a secret.
That said, it's not final, so I wouldn't quote me on anything yet.


I'm going to offer my take on the event system Nicepoint suggested earlier. I propose calling these "node-scripts" (in contrast to proper scripts, which would be written in an embedded language like Ruby or Lua):


This will kill the player who activates the node-script. How does it work? Well, here's what it looks like when you show the "settings" for each node:


The Activation node is a detector node to the script. When a player clicks on the brick, it will cause all Activation nodes on that brick's node-scripts to output data of type Event. Event basically just holds data referring back to whatever caused the Event - in this case, it would hold a reference to a Entity (such as a player!), a Client, and a Brick (which in most cases will simply be the brick the node-script is being run on, and thus is redundant; however, there may be situations where you're running the node-script from somewhere else). When viewing the settings dialog for Activate, it only shows information about it, since there's no settings to adjust. The Event that the node outputs is then piped into Select, which is a processor node. Select takes an Event and "extracts" the information from it; in its settings dialog, there is a drop-down box to choose which data to extract. Note that it includes various data-types that are NOT available on the event, and thus would cause an error if the node-script were run. In any case, Entity is selected, and so the Select node outputs an Entity (because the output data type can vary, it has an asterisk). Finally, this is fed into the Kill effector node, which affects the outside world. In this case, it takes in an Entity, and kills it. It has two settings which determine its behavior, but has no outputs. (In theory, you could have it output a Boolean with information on whether it successfully killed the input Entity.)

I could come up with a more complex example if desired. Or just play LittleBigPlanet. Or Wiremod for Garry's Mod.

EDIT: I've sort of realized that the Event datatype and Select processor are unnecessary - the event could simply have multiple outputs, one for each possible target.

that is a really sick mockup

better names: input/output/map nodes

eg not restricted to interpreting them as purely game-physical connected, eg “onVariableTrue” kinda barely skirts “detection” definition as detection implies something happened, not something was evaluated. same with output, and mapping is the proper term used in math/computer science
« Last Edit: October 29, 2017, 03:51:36 AM by Conan »

I'm going to offer my take on the event system Nicepoint suggested earlier. I propose calling these "node-scripts" (in contrast to proper scripts, which would be written in an embedded language like Ruby or Lua):


This will kill the player who activates the node-script. How does it work? Well, here's what it looks like when you show the "settings" for each node:


The Activation node is a detector node to the script. When a player clicks on the brick, it will cause all Activation nodes on that brick's node-scripts to output data of type Event. Event basically just holds data referring back to whatever caused the Event - in this case, it would hold a reference to a Entity (such as a player!), a Client, and a Brick (which in most cases will simply be the brick the node-script is being run on, and thus is redundant; however, there may be situations where you're running the node-script from somewhere else). When viewing the settings dialog for Activate, it only shows information about it, since there's no settings to adjust. The Event that the node outputs is then piped into Select, which is a processor node. Select takes an Event and "extracts" the information from it; in its settings dialog, there is a drop-down box to choose which data to extract. Note that it includes various data-types that are NOT available on the event, and thus would cause an error if the node-script were run. In any case, Entity is selected, and so the Select node outputs an Entity (because the output data type can vary, it has an asterisk). Finally, this is fed into the Kill effector node, which affects the outside world. In this case, it takes in an Entity, and kills it. It has two settings which determine its behavior, but has no outputs. (In theory, you could have it output a Boolean with information on whether it successfully killed the input Entity.)

I could come up with a more complex example if desired. Or just play LittleBigPlanet. Or Wiremod for Garry's Mod.

EDIT: I've sort of realized that the Event datatype and Select processor are unnecessary - the event could simply have multiple outputs, one for each possible target.

Cool

How about the "utility" nodes? If you'd like the event to do two different actions depending on a variable that the entity has? Or a timer node, or maybe even Logic Gates?

I like the order in which event lines run now, with it being input->target->effect->(effect parameters)

I like the order in which event lines run now, with it being input->target->effect->(effect parameters)

the eventing system in blockland works well enough, but it could definitely use some more things like if-else logic and input event parameters

having input->target->effect->(effect parameters) is a good, simple system for people who aren't looking to do anything too complex, but having some more advanced features would be nice
« Last Edit: October 29, 2017, 01:19:53 PM by Electrk² »

the eventing system in blockland works well enough, but it could definitely use some more things like if-else logic and input event parameters

having input->target->effect->(effect parameters) is a good, simple system for people who aren't looking to do anything too complex, but having some more advanced features would be nice
Exactly my thoughts, I was thinking maybe a Basic/Advanced tab that changes around the style of node editing.

By the way i forgot to mention how absolutely beautiful that mock up is. Like holy crap that's music to my eyes.
This would be the easy to understand "Basic" version, and i imagine the "Advanced" version to be something more akin to Blender's node editor.

Exactly my thoughts, I was thinking maybe a Basic/Advanced tab that changes around the style of node editing.By the way i forgot to mention how absolutely beautiful that mock up is. Like holy crap that's music to my eyes.
This would be the easy to understand "Basic" version, and i imagine the "Advanced" version to be something more akin to Blender's node editor.


holy stuff this looks amazing so far

better names: input/output/map nodes

eg not restricted to interpreting them as purely game-physical connected, eg “onVariableTrue” kinda barely skirts “detection” definition as detection implies something happened, not something was evaluated. same with output, and mapping is the proper term used in math/computer science
There would be no need for onVariableTrue events; I'll draft up a mock-up of a more complex example in a bit.

how good will the mod support be

how good will the mod support be
For the game in general or for events specifically?


(Note: These don't have to be the final datatypes, and there are good reasons to modify some of these). Anyway, here's another, slightly more complex, example:


First, I've removed the Select node in favor of multiple outputs from the detector. It's a holdover from Blockland-style events, but with a flexible node-style system with multiple inputs and outputs, there's no reason for it to exist. Second, I've introduced the Vector data type, which holds several numbers; Vec3 holds 3 numbers, and is used for things like position, size, rotation, and velocity. You can perform arithmetic on vectors like you could numbers, such as vector addition, vector subtraction, scalar multiplication (where a vector is multiplied by a scalar, which is just a single number), dot product, and cross product. So this node-script detects when a player collides with a brick, and inverts the player's velocity (by multiplying it by -1). This causes the player to "bounce" off the brick.

This doesn't make use of things like loops and if-then-else statements, which I'm still thinking of a way to implement elegantly. Additionally, I think there should be Set Property (inputs: String, Any; outputs: None) and Get Property (inputs: String, outputs: None) nodes, which can read/write arbitrary data to certain objects. For instance, you can use Set Property with inputs "cash" and 32, and then later, you can use Get Property to check if they have enough cash to buy something. You can also use this in place of Set Velocity by using "velocity" as the property name, but you need be careful, because these values do require specific data types, and you can cause an error if you're careless and try to set velocity to a String.
« Last Edit: October 29, 2017, 03:53:21 PM by TristanLuigi »