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

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



Here's a more complex version of my system.

This event works as a shop for a single item.

1. The OnActivate node is triggered and the first combination of nodes checks if the client has bought this item before, if they have then the divider node sends signals down the paths B, C and D. If not then A.2. In the case that the B, C and D signals are sent, then B will add an item to the player's inventory. C will message the client about the item and D will make the activated brick play an OK sound.3. In the case that the signal goes up the A path, then the event will check if the client has enough score to purchase the item. If the player has enough points then it will send signals down paths A, B, C and F. Otherwise D and E.
4. In the case that the player has enough points, the signals will trigger a message of purchase, an addition of a variable which satisfies section 1 in the future, a reduction of points to pay the item and a signal down to do the same as section 1's path B.5. In the case that the player doesn't have enough points, the paths D and E will display a message of a failed transaction and cause the brick to emit a NO sound.

Yes, I've noticed that the purchasing event has no sound.


(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.
I'd say mine would work as a simple system and Tristan's would work better as a more advanced system.

Ok, I finished my own mock up; here's how i imagine the advanced system, which would be completely focused on being dynamic, adaptive, and flexible, as apposed to being focused on being easy to use.

So there are varying types of logic based nodes, specific events and actions are selected on a per node basis. For example, if you want to detect a player collision, you would put down an "On Event" node and select Collision, and then specify that you want the specified collision to be with a player.

Like in Blender, each node has a number of color coded connectors, which i'm calling plugs, the different colors represent what nodes are compatible, due to the differences in data and uses that the plugs have.

So to explain the nodes and Plugs in the coming example, lets start with the plugs. I only needed a few in the example, but i'm sure there are one or two to come.





The event plug is what connects the logic. Chains of these create the spine of the event system, at their most basic they act as sort of a trigger to activate the next logic in the chain they're connected to.
Every brick has this plug, to make logic work, you simply plug it into the first node in the network. You'll see what I mean in the coming examples.





This transfers raw data from a brick or event to have specific information extracted. It's everything that there is to know about the brick or event it's being pulled from.





This transfers a single clean variable to be tested, used, or have logic applied to it in some way.



Now for nodes:



The Brick node is used for any and all references to bricks, the name field is important, because if it has a name applied to it, it will reference all bricks with that name, if there is no name applied, it will only reference the single brick that the event is taking place on, both with data output, and event logic. This is incredibly powerful, because a talented eventer could have a huge build, with loads of stuff going on, (My old tycoon for example) but all logic (events) is being done in one brick, as appose to being all over the place.
And holy crap, if i could have only done that in my tycoon build, I had SO many 1x1x1f plates just because i needed logic relays, not to mention literally every single brick in every single tycoon having events, and tons of events going on in the admin room; I wish that was all handled by one brick per tycoon.





The On Event node would have something like a drop down menu to select actions, this would be akin to the input section of the legacy event system.
As long as it's getting a signal, when the event occurs it will output a signal for as long as it's occurring. For example, a brick activation would output for one frame, but a player collision would output for as long as the collision is happening.





The If Then Else node will take 2 variables and compare them if they're compatible. If it output's true, the Then plug will fire, if it's not, the Else plug will fire.





The Extract Data node will extract the selected information and pass it on as a usable variable.





There are many logic nodes, but Switch does exactly what it looks like, every time it gets a signal, it will switch which output it will transfer the signal to. The graphic displays which way the next signal will go next.





This one needs more work. Basically the Action node will do whatever action is selected to whatever item who's name/id is provided by the variable plug. If nothing is provided, it will only effect the bricks connected directly to the logic network via "Event Start"



So here's an example:

I want to make a light switch that lets me and only me turn a light on and off. I name the brick acting as the light switch "Light Switch" and the brick acting as the light "Light". I enter the light switch's event system and make this:


Keep in mind that i could have kept the "Light Switch" reference name empty, and it still would have worked, because the events are taking place inside the Light Switch brick, and if there is no name applied to the brick node, it will only reference the single brick that the event is taking place on.

This is powerful, I mean, imagine that i connected Event Start on the Light brick reference, to the On Event node, now that logic would also take place when i activate the light brick too, even though that brick has no logic of it's own.

Now there are contradictions and flaws in this example, like for example, getting information about what player is activating the brick from the brick itself as apposed to the On Event node, but this is just a first draft, still working everything out, but that information would come from the On Event node, not the brick itself.

Questions?
« Last Edit: October 29, 2017, 07:55:43 PM by Yin Yang »

Games like these would be targeted to younger people. At 10 years old I wouldn't be able to follow either YY's or TL's second design. Keep the core simple and add an advanced option for those that want it.

That being said TL's initial is easily my favorite.

Games like these would be targeted to younger people. At 10 years old I wouldn't be able to follow either YY's or TL's second design. Keep the core simple and add an advanced option for those that want it.

That being said TL's initial is easily my favorite.
My second example is basically the same system as my first. It's a more complex event chain (since the goal is more complex), and I replaced the "Select" node with multiple outputs, which is more intuitive.

Also, I don't think having two node systems (basic and advanced) in addition to actual scripts is a good idea.
« Last Edit: October 29, 2017, 08:51:55 PM by TristanLuigi »

the stuff -> the good stuff
                                       \
                                         > the game

give me my medal

My second example is basically the same as my first, it's just a more complex event chain, and I replaced the "Select" node with multiple outputs, which is more intuitive.
It's not the flow of it or anything I have difficulty with, it's more of the terminology. Again, as a small child I wouldn't know what a vector or scalar quantity were or how they relate to whatever else.

Maybe it's just me but I wouldn't throw large or complex words into a system that everyone would use.
At least not in the default / simple version of the system.

It's not the flow of it or anything I have difficulty with, it's more of the terminology. Again, as a small child I wouldn't know what a vector or scalar quantity were or how they relate to whatever else.
Then perhaps we would be doing a good thing by introducing children to vectors ;)

I guess you could have simpler effectors that do the same thing you could otherwise achieve, but with fewer nodes. For instance, there could be a "Multiply Velocity" effector, which simply takes an Entity and multiplies the velocity by a constant within the event. However, then you have to create a large quantity of effectors, most of which are redundant.


Then perhaps we would be doing a good thing by introducing children to vectors ;)
Or could scare them off from the entire concept.

Think Blockland's way of teaching is pretty good as is.
Gradually progressed from easy to understand language for kids like activate or touch, to some of the more complex event mods such as VCE, then finally to actual scripting language for those that went that far.

To me it seems like people are developing ideas for a system that has scripting level lanaguage and functionality for those that will use it, in junction with those that just want to make a brick disappear for 5 seconds.

It's very early to say how it goes, and by no means are any of the designs bad, just think it's something to be wary of when designing the final system.

Or could scare them off from the entire concept.

Think Blockland's way of teaching is pretty good as is.
Gradually progressed from easy to understand language for kids like activate or touch, to some of the more complex event mods such as VCE, then finally to actual scripting language for those that went that far.
The problem is that Blockland's system is actually pretty terrible; it's very static, and doesn't allow for ANY input data at all. The output events are much better, but still relatively limited. VCE is a decent way of extending the system given what it does, but it's not a good pattern for a system from the ground up.

I think LittleBigPlanet 2 and 3 provide a good example of a system that is both beginner-friendly, and quite flexible; however, it has a major flaw, which is that the only data that can be passed between nodes is numeric (0-100%). On the other hand, Wiremod (for GMod) allows all types of data, but can be a little daunting at first. Ideally we would be able to strike the best of both worlds.

Yin Yang also brought up Blender's node system, which is also very good.

My event idea is in it's very early stages and i am by no means a graphic designer so Tristan's is going to look and feel way better, as well as just be a better design for people who are new to these kinds of logical event systems. also there are ways around vectors, although vectors aren't hard for a 10 year old to understand if he actually cares, i speak from experience, like just having a direction node, and being able to pick from a drop down list of directions.

Also the game wouldn't be targeted directly at younger people, the game is targeted for people who want to play a lego based block building game; and while many of those people are going to be young, a lot of them are also going to be teens or adults, I'm 20 and I want to play this. It's not just for younger kids who wanna doodle around, which is what the more simplistic, picture based, colorful Basic system would be for, its also for people who legitimately want to use this as a medium for creating their own functioning game, or do other impressive things, which is what the more flexible, adaptive, dynamic Advanced system would be for. Also I wouldn't anticipate a scripting based event system, if you want to script events, you can make an addon or a mod; the design of the advanced node based event system would be as powerful as directly coding, just, instead of typing characters, your using an expandable, basically modular visual interface.

I really do love Tristan's interface, the only problem is that it's basic and limiting;
I really love my own interface, the only problem is that it's complicated and disconcerting;



Many many things in modern software have a basic and advanced setting, why is having that in the event system not such a good idea?
« Last Edit: October 29, 2017, 10:22:57 PM by Yin Yang »

I really do love Tristan's interface, the only problem is that it's basic and limiting;
I really love my own interface, the only problem is that it's complicated and disconcerting;
Interesting. Do you have a Steam or Discord handle I could talk to you over? Maybe we can hammer out a design that accomplishes the best of both.

Many many things in modern software have a basic and advanced setting, why is having that in the event system not such a good idea?
I guess it's not a big deal, but you would be making your users learn two different systems that are still quite similar, which in my opinion is a recipe for confusion. There already is an advanced setting, in some sense - scripts written in proper code.

Interesting. Do you have a Steam or Discord handle I could talk to you over? Maybe we can hammer out a design that accomplishes the best of both.
I guess it's not a big deal, but you would be making your users learn two different systems that are still quite similar, which in my opinion is a recipe for confusion. There already is an advanced setting, in some sense - scripts written in proper code.
tristan is correct on this. the more “versions” you make to attempt to make it easier the less coherence you have overall, and addon developers would have to do double the work potentially to make it work on both versions, as well as learn how to use both versions

if you can make a reasonably simple system that supports complex stuff, thats better than having an advanced mode which may scare off people who can actually use it but think they’re not good enough. it also shows you dont have a clear idea what exactly the eventing system should support: you want it to be easy but you also want it to have advanced functionality - you cant just take both options and then call it a success. or, in other words, you cant have your cake and eat it too.
« Last Edit: October 30, 2017, 02:04:27 AM by Conan »

How about making the system simple on the surface, with only one datatype and then making an advanced system option with the other datatypes? They wouldn't exactly be different systems, just a simple mode with pre-made functions like: reverseVelocity which is just Tristan's example put into a single node and the more advanced system.

all this discussion is veering dangerously close to actual scripting language and thats a problem cause i dont think any of us are trained well in language development and how to handle scope/compilation and prevent exploits from existing

bad scripting languages could allow clients to inject code into a server, and possibly worse (like inject files into the server computer) depending how integrated with the engine the system is