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

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

-snip- animation would be automatically mapped -snip-

This is what happens when you 'automatically map' animations between models: https://www.youtube.com/watch?v=fk755V8bq18

I've been thinking about an eventing system based on nodes. Here's a rough concept drawing I made.


The nodes would be based on a 2D plane and they'd function in a circuit-like manner with 4 different types of nodes.
Some nodes would have another level of customization which would allow changes like: drop-down selection boxes for item, projectile, vehicle, etc. spawning, tic-boxes for toggling things like collision, rendering, etc. and text fields for writing down messages or variables.

The 4 types of nodes are: Trigger nodes, Target nodes, Action nodes and Utility nodes

Trigger nodes are basically all of the onSomething events and can be recognized from the left pointing nozzles and one right pointing output.

Target nodes are the events which decides what the following action nodes will interact with. They have a triangular input on the left and right pointing output.

Action nodes decide what happens to the target given by a former target node. They have a triangular input and nothing on the right side.

Utility nodes have an "output" node on both sides and they can also be attached to the right side on Trigger and Target nodes.


With this kind of system, it would be possible to compress VC-events under a single trigger. It would also make the layout a little bit more simplistic. What do you lot think?

ur asking basically for blueprints, its a thing used in a lot of out-of-the-box game engines these days. definitely doable and proven to work so its not a bad idea, only problem is replicating the system ingame and making it possible to create your own “node types” as addons

only problem is -||- making it possible to create your own “node types” as addons
I don't think so, If i were to plot out the logic of it, I could probably have a system planned by tonight. C# and unity are extremely flexible, in most code it's not really a matter of "Can i do", it's more of a matter of "How do i do". And a lot of things are easier then they may seem to someone who's not a coder. and

only problem is replicating the system ingame -|
I haven't tried, and i have occasionally been very wrong when I've said this, but i think that will be super easy once he has the bricks in a more final state. Making the dynamic interface wouldn't exactly be the hardest part of the game.

Although, addons being code-able in anything that's not C# or JavaScript... it is a mystery to me how he plans to accomplish that; because Unity3d supports those two languages and he could just directly run the code in an addon, where as Python? Idk.
« Last Edit: October 25, 2017, 02:08:47 PM by Yin Yang »

I don't think so, If i were to plot out the logic of it, I could probably have a system planned by tonight. C# and unity are extremely flexible, in most code it's not really a matter of "Can i do", it's more of a matter of "How do i do". And a lot of things are easier then they may seem to someone who's not a coder. and
I haven't tried, and i have occasionally been very wrong when I've said this, but i think that will be super easy once he has the bricks in a more final state. Making the dynamic interface wouldn't exactly be the hardest part of the game.

Although, addons being code-able in anything that's not C# or JavaScript... it is a mystery to me how he plans to accomplish that; because Unity3d supports those two languages and he could just directly run the code in an addon, where as Python? Idk.
u are talking to a coder

i think you’re vastly underestimating the effort it would take to replicate said systems in a game. its less about writing the code and more about designing it in a way to support the things you want it to support. since you also way underestimated the amount of work it would take to make a modular animation system im not surprised, but you need to tone back the “this is not really that hard” approach to all these ideas.

coding when it comes down to it is really only 50% or less of the time writing actual code: most of the time is spent designing the system to be adaptible and clean and able to support things you plan on adding in the future

I don't want to steal the attention again so i'm going to continue this conversation as pms. This is quickly drifting away from Ghost's game and into "I'm right no i'm right" and i don't want that to happen.

I've been thinking about an eventing system based on nodes. Here's a rough concept drawing I made.


The nodes would be based on a 2D plane and they'd function in a circuit-like manner with 4 different types of nodes.
Some nodes would have another level of customization which would allow changes like: drop-down selection boxes for item, projectile, vehicle, etc. spawning, tic-boxes for toggling things like collision, rendering, etc. and text fields for writing down messages or variables.

The 4 types of nodes are: Trigger nodes, Target nodes, Action nodes and Utility nodes

Trigger nodes are basically all of the onSomething events and can be recognized from the left pointing nozzles and one right pointing output.

Target nodes are the events which decides what the following action nodes will interact with. They have a triangular input on the left and right pointing output.

Action nodes decide what happens to the target given by a former target node. They have a triangular input and nothing on the right side.

Utility nodes have an "output" node on both sides and they can also be attached to the right side on Trigger and Target nodes.


With this kind of system, it would be possible to compress VC-events under a single trigger. It would also make the layout a little bit more simplistic. What do you lot think?
reminds me of the "build your own computer" which is basically just a raspberry pi with programs for kids to "learn how to code." Does anyone remember or know what I'm talking about?

why don't all you guys make one game  :cookieMonster:
I like that idea! Instead of having 3 rival projects, we should just combine them into one. I'm getting burnt out working by myself anyway.

I've been thinking about an eventing system based on nodes. Here's a rough concept drawing I made.


The nodes would be based on a 2D plane and they'd function in a circuit-like manner with 4 different types of nodes.
Some nodes would have another level of customization which would allow changes like: drop-down selection boxes for item, projectile, vehicle, etc. spawning, tic-boxes for toggling things like collision, rendering, etc. and text fields for writing down messages or variables.

The 4 types of nodes are: Trigger nodes, Target nodes, Action nodes and Utility nodes

Trigger nodes are basically all of the onSomething events and can be recognized from the left pointing nozzles and one right pointing output.

Target nodes are the events which decides what the following action nodes will interact with. They have a triangular input on the left and right pointing output.

Action nodes decide what happens to the target given by a former target node. They have a triangular input and nothing on the right side.

Utility nodes have an "output" node on both sides and they can also be attached to the right side on Trigger and Target nodes.


With this kind of system, it would be possible to compress VC-events under a single trigger. It would also make the layout a little bit more simplistic. What do you lot think?
I really like the concept. =) That reminds me of the programming interface from Lego Mindstorms.

That reminds me of the programming interface from Lego Mindstorms.
Thats interesting, can you share some screenshot or something?

It would be nice if the user could just make an avatar model, give it an animation skeleton, give it animations with specific names tying  fill in a txt with various attributes of the character, optionally, so only the attributes you put down would be changed. For example, if by default the player has 100 health, weighs 20 pounds, and can walk at 1.5 m/s, in this text file you could put
playerHealth = 300;
playerSpeed = 2;
and then your new character would have 300 health, weigh 20 pounds, and walk at 2 m/s.

The same could go for animations. Any animations that the player file doesn't have in stock with specific names would just resort to the default animations.

this is just blocklands playertype system, you realise?
Like its literally exactly what we have already. If you don't like the default player in Blockland, you can just make a playertype for yourself. If you don't want to animate it, you can give it the same node names and bones as the default model and reuse the animations.

this is just blocklands playertype system, you realise?
Like its literally exactly what we have already. If you don't like the default player in Blockland, you can just make a playertype for yourself. If you don't want to animate it, you can give it the same node names and bones as the default model and reuse the animations.
Oh snap, really? I never looked into it, I just on the spot pitched something that seemed like it would be the easiest from the Add-on creator's pov... I guess if it ain't broke...

Since we're on the topic again, I would make the player model and player stats different mods, maybe if someone really wants to have them both together they can make it a third thing.

So a PlayerModel Add-on would just be the new player model, animations, ect. It could be changed from the avatar customization. menu
a PlayerType or PlayerStats or whatever Add-on would just be the stat changes. And would have to be changed ingame like how you have to change in Blockland
and a PlayerMode Add-on would be both together. And would have to be changed in the game.

Also want to say that when i post an idea for a system on a forum, i'd deliberately leaving out a lot of steps and logic so that A: I'm not typing all day and B: So that people who have no idea how to code will still get the idea with little to no effort.
« Last Edit: October 28, 2017, 02:32:54 PM by Yin Yang »

I like that idea! Instead of having 3 rival projects, we should just combine them into one. I'm getting burnt out working by myself anyway.
I really like the concept. =) That reminds me of the programming interface from Lego Mindstorms.

You just stole what i was going to say

when i saw it i was like 'lego mindstorms code the little robot' and you beat me to it

looks amazing so far, keep up the good work and get a free  :cookie:

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.

EDIT2: Icons from game-icons.net.
« Last Edit: October 29, 2017, 10:48:55 PM by TristanLuigi »

Thats interesting, can you share some screenshot or something?
Sure, this is what it looked like back then:


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.
I love it, perhaps multiple processor and effector nodes can be strung together as well, based on subsequent detector nodes that are used.