Introduction
____________________

Hello there! I am IMAWarriors and today, I am going to provide a suggest for the Scratch editor I think will benefit all users and won't be too tricky for new users! What I am going to be going over today is the idea of particle effects, what they would do for scratch, and how they would be implemented!

In this forum post, I am going to explain how this would function effectively. I find it often that the Scratch team rejects ideas because they are either too vague on how they would be implemented or they are just too complicated for younger scratchers. I will be trying to combat all of these points today, but at the end of the day, if the Scratch team chooses not to add my idea, I respect that and will not push.

I have many other suggestions, however I think this may be the third most pressing issue with Scratch. The issues we will be going over later. I want to first explain how I am going to go about explaining this so that it will be easier for you to understand and for maximum clarity. Thank you!




Table of Contents
____________________

• Introduction - How I am going to go about things
  
  
• Table of Contents - Run-down of what I am going to talk about
  
  
• What is a Graphics Card? - I will explain to you what a graphics card is
  
  
• What is a Particle? - Concluding necessary vocabulary, I will explain the definition of a particle and why they would be good
  
  
• Implementation - How would particles work?
  
  
• Conclusion - My wrap-up
  
  
• FAQ - Frequently or just asked questions
  
  

What is a Graphics Card?
____________________

A Graphics Card–or graphical processing unit, also known as GPU–is found in your computer, and despite the quality of it, every computer has one. It allows information to be transferred between the computer screen and the computing machine. It essential stores code in a graphical programming language that tells the computer what to put on the screen. Being purely graphical in storage, the storage is minimal and allows for manipulative use.

Wikipedia wrote:

Graphics hardware is computer hardware that generates computer graphics and allows them to be shown on a display, usually using a graphics card (video card) in combination with a device driver to create the images on the screen.

What does any of this have to do with a Graphics Card, though? Essentially, graphics are very small and take up little space. They have little use other than visual effect, but this is good if you only need visual effect. In computer software, game sometimes have minimal effects–purely visual–stored on the Graphics Card rather than the internal drive or whatever the game is stored on as it takes up less space in the CPU and instead takes space in the GPU.

Graphics Card data could be used greatly for visual effects, and is. These effects that are created by the graphics card spend little to no time in the internal engine of the game and allow the game to conduct itself productively and efficiently, taking up practically no space as it is only a graphical effect stored in pixels on your monitor screen.




What is a Particle?
____________________

A particle is any piece of data–usually in dots or squares–that is stored using minimal data on the GPU to create immense visual effects without causing tremendous lag disrupting the flow of the game. Particles can be used as effects to make things more satisfying, professional, and visually appealing. Particles cannot interact with anything on the CPU and do not rely on this, but instead their own internal programming.

Particles are simply little graphic effects that can look as ridiculously intense as they want without creating lag or causing gameplay issues. The obvious trade-off here for having such an incredible tool is the fact that they cannot interact with other objects. If they could, they would be no different from Clone Instances and would–depending on their use–affect game performance.

However, the tradeoff is minimum as the effects of particles would and have created great looking games. The idea that I am continuously amusing is adding particle graphical support to scratch via extension.

Particles would be tremendous help in creating visual programs without having to use clones and other things that take up a decent amount of space. Imagine this: Clones are very useful, however using them is only at a great expense. There are only 300 clones available at any given time, and even below 300 you can still receive lag.

The issue here is that while clones are useful, it is trivial to use them for something so seemingly pointless as particles as you could only have so many and you might want to have 80 particles at a time. So rather than trying to figure something out, a lot of scratchers skip it. They don't add particles and we get relatively dull games that could be just that much better, was there a particle element.




Implementation
____________________

So far, I have made a case for the implementation of particles. It might seem like a good idea, but this case begins to beg the question… How would particles be added? How would they function? What would they do, realistically? Can we have a visual representation of what this looks like?

Now, to this, normally I would love to give a creative solution. But the truth is, this idea isn't easy to implement. Obviously, once added, it would function superbly, but it would need to be added correctly. How could this be done? To answer this, I am going to give a list of possible ways we could add this in order to make it work and keep Scratch still the same.

1. Clone Behavior – My initial idea was to implement this similar to the way that clones are implemented, but as an extension. This would give a lot of freedom and would certainly be easier to implement, but it also has some negatives to it. Essentially, the way it works is with a hat block that says “When I start as a particle” and beneath it, you would put your code and follow the procedure until it is given and eventually delete itself
   
   

   when I start as a particle :: hat #e6ce81
   go to x: (100) y: (100)
   switch costume to [costume1 v]
   set [ghost v] effect to (100)
   repeat (10)
   change [ghost v] effect by (-10)
   end
   wait (0.4) secs
   glide (0.1) secs to x: (0) y: (0)
   repeat (10)
   change [ghost v] effect by (10)
   
   end
   delete this particle :: #e6ce81 cap

   
   

   Pros:
   - Relatively easier for the scratch team to implement
   - Simple to understand and use
   - Beneficial in programming freedom
   
   Cons:
   - Would cause syntax errors if someone tried to use live sensing (repeat until touching <>)
   - Lack of “delete particle block” would leave the particle suspended
   
   

2. Limit Freedom – The idea of this is that there are only a certain number of particle effects, making it easier for younger users to use without errors. It would be similar to the graphic effect block in that there is a drop down menu of possible effects and the effect you choose will appear in the particles. You would chose what costume they take form in, their fade in, their action, and their fade out. This could be something like the following:
   
   

   when green flag clicked
   switch costume to [costume1 v]
   
   when I receive [absorb-orbs v]
   go to x: (pick random (-100) to (100)) y: (pick random (-100) to (100))
   create particle appearance: [fade in v] disappearance: [fade out v] action: [glide to sprite Player v] in secs (0.2) ::  #e6ce81

   
   

   Pros:
   - Simple to understand and add
   - Allows young scratchers to understand what they are doing
   - Creates a simple way to add effect
   
   Cons:
   - Not much freedom in what you can do
   - Wouldn't work well for certain scenarios
   
   

   
   The idea is rather simple, but it would be quite limiting. My favorite option for this idea is the last suggestion.
   
   
3. New Part Type – So… what is this? This one is hard to explain, but for this idea, there are two routes you can go:
   
   1.) Creating a subclass within a sprite to manage and run particles
   2.) Creating an entire new class of category for particles
   
   Okay, let's start with the first idea. What would this look like? Basically, there are three subclasses at the moment: Scripts, Costumes, and Sound. This idea adds another tab here called “Particles” where you have a custom UI to design the creation, life, and death of this particle. You could then call this particle to run in your scripts. This would be some editor where you draw your particle and program the life and death of it. I don't know how scratch would be willing to do this, but to be honest, if they were willing this would probably be the best way to implement particles.
   
   

   create particle [orb v] :: #e6ce81
   create particle [orb v] and wait :: #e6ce81

   
   The second idea would basically have to add an entire other class. At the moment, there is just the Sprites and the Background. Imagine adding another class called “Particles” that would basically have you create particles, program them, and call them via external scripts. But I hear your question: how do you keep out the syntax errors of using sensing blocks? The answer is simple: don't allow these blocks in this editor. See, the background can have scripts, but it restricts some blocks like the motion blocks. You would program something the way you would program a sprite, except you would only define particles here. (You would also restrict access of hat blocks except the following one)
   
   

   when particle [orb v] is called :: hat #e6ce81 // There would be an option--similar to the broadcast drop-down--to add a new particle effect
   go to x: (100) y: (100)
   switch costume to [costume1 v]
   set [ghost v] effect to (100)
   repeat (10)
   change [ghost v] effect by (-10)
   end
   wait (0.4) secs
   glide (0.1) secs to x: (0) y: (0)
   repeat (10)
   change [ghost v] effect by (10)
   
   end
   delete this particle :: cap #e6ce81 
   
   create particle [orb v] at x: (0) y: (0) :: #e6ce81 
   create particle [orb v] at x: (0) y: (0) and wait:: #e6ce81 

   
   

   Pros:
   - Would be really easy for developers to use
   - Simple enough young programmers could understand
   
   Cons:
   - Difficult to develop
   - Would take a lot of time for the Scratch Team to implement
   
   

   
   

Conclusion
____________________

I worked very hard on this forum post, so please tell me what you think about it, what improvements can be made, and what questions you have about how it works. I do ask that you don't tell me what you think about it until you're sure you understand my ideas. I really think these ideas would help to bring Scratch full circle for young and old users. It would help to make scratch easier for everyone to use and give it more capabilities that would be immense help to many others.

I understand none of these ideas may ever make it to scratch, and a scratch team member may not even ever see these ideas. But I think they would work really well if executed correctly. All I ask is that I make myself heard and that someday in the future, we might even see some form of this on scratch.

Again, thank you so much for your time. There will be a developing FAQ below where–when people ask questions–I will answer them and if I think they would help, I'll add them. I will also add some sample questions for your own sake. I am so glad that you read this, and really hope that maybe my idea might see some form of implementation into scratch!

I really would like to hear your feedback on how this could be made better! So talk here, or visit my profile and contact me there at IMAWarriors.

Scratch On!


Developing FAQ
____________________

IMAWarriors wrote:

If Scratch DID add this, what effects would they support for your second idea?

IMAWarriors wrote:

I'm not sure. I was thinking maybe a “flame” or “sparkle” or “ghost” effect. Some default effects that are in a lot of powerpoint applications

____________________

IMAWarriors wrote:

What would the layering look like on this?

IMAWarriors wrote:

Particles will create at whichever layer the sprite who called the particle is at

____________________

IMAWarriors wrote:

Would there be any other blocks supported?

IMAWarriors wrote:

Perhaps. I did not think that far ahead, but maybe there would be other effects created by the Scratch team

____________________

ScratchCatHELLO wrote:

What if somebody has an integrated graphics card and it sucks (like mine) and somebody else goes overboard on particles?

IMAWarriors wrote:

Well there would obviously be some limit to the particle amounts, but it doesn't exactly matter the quality of your graphics card relatively. Even with a limit of 5,000 or 9,000 particles, the idea is that the particle is visual data stored on your graphics card as opposed to the CPU which takes up a lot of space (clones for example). Basically, by just having them perform some action with no interaction, they could be quite useful in graphic effects.

would there be a limit on how many you can have, like clones have

Honestly, I'd support just because of the effort you put in, but I actually think the suggestion is a good idea and I would personally like this to be implemented.

Thank you very much!

TopCode wrote:

would there be a limit on how many you can have, like clones have

There would probably be, but it would be very large, as in several thousands as more space can be stored on the GPU

Wow! Great post! Support as particles I think can make patflormers easier (defo scrolling) without having to do that in costumes

This is probably the highest-effort OP I've ever read. I don't know much about GPUs, so this question is probably stupid: What if somebody has an integrated graphics card and it sucks (like mine) and somebody else goes overboard on particles?

ScratchCatHELLO wrote:

This is probably the highest-effort OP I've ever read. I don't know much about GPUs, so this question is probably stupid: What if somebody has an integrated graphics card and it sucks (like mine) and somebody else goes overboard on particles?

Thank you That's a good question and probably the reason Scratch would have to implement some sort of particle limit. But it doesn't really matter the strength of your graphics card as–in comparison to CPU storage–it takes up extremely little data and is only stored essentially on the screen. The relative “excessive” amount of particles on the GPU however is much much larger. So even if your graphics card was very slow, it should still be able to hold a practical amount of particles as long as they follow their action and delete themselves. The graphics card won't be overloaded as the only thing that helps the GPU keep the lag down anyways is the fact that information on the graphics card is processed so quickly as just visual. But I understand your concern, and just for practical purposes, there would likely be some sort of limit, whether it be a several thousands even with a poor quality GPU.

Bump

dertermenter wrote:

Bump

anyway, support because this would be useful for a wide range of things

ScratchCatHELLO wrote:

dertermenter wrote:

Bump

it was 2nd paged

Support, it's very well made.

Bump

Bump

Particles seem kind of similar to clones in how they work. They're also not used that much, especially not in 2D games.

Greg8128 wrote:

Particles seem kind of similar to clones in how they work.

The difference is all in computation power as described in this quote:

OP wrote:

Particles are simply little graphic effects that can look as ridiculously intense as they want without creating lag or causing gameplay issues. The obvious trade-off here for having such an incredible tool is the fact that they cannot interact with other objects. If they could, they would be no different from Clone Instances and would–depending on their use–affect game performance.

Plus, using particles for clones would quickly use the 300 clone limit in Scratch, not letting you use anymore for other parts of the project.

Greg8128 wrote:

Particles seem kind of similar to clones in how they work. They're also not used that much, especially not in 2D games.

Yes, in addition to what @fdeerf said, particles can be used for whatever purposes they find. If you don't use particles, that's fine. But I think they would reduce a lot of gameplay issues and allow for more flexibility when programming, being that you can use as many as you want. I ask that you read the entire article to grasp a better understanding of my proposal before attempting to disprove it, but you are free and you may do as you wish. I appreciate the feedback!

Bump

This is really interesting, I can see all sorts of places for this to be used, like a platformer where you follow a glowing orb, a presentation with particles that follow your mouse, etc

Are you even sure this is possible at all in JavaScript? I'm a JavaScript developer and I don't think there's a developer-selected distinction between the CPU and the GPU. Maybe I'm revealing that I'm a total idiot right now or maybe there's some obscure function for this that is kind of okay for me to have not known about.

I personally feel like this distinction would be much more confusing than actually useful; having a second type of clones for no reason but optimization isn't really the easiest thing to understand for someone who doesn't understand optimization or what a GPU is, and I feel like this would lead to a lot of questions like “what is the difference between these two features” and “why can't my particles detect whether or not they are touching something”.