Scratch

WARNING:
A lot of scratchers are confused, and seem to think that this guide helps shrink the size of projects. The only thing it shrinks is perhaps the number of scripts needed,  or the time needed to make games, because this is a SPEED guide not a SIZE-REDUCTION guide. If you need to make a big project smaller, perhaps change long pieces of music into little loops, taking far less space but still sounding good. Here, you can learn how to improve the speed of projects if they are running slow, improve how long it takes to make long and harsh scripts, and also how to find glitches.

Contents
0. Random Tip
1. Introduction/Proof that it does work
2. Tips on making games faster
3. Tips on making programming faster
4. Tips on glitch hunting

---------------------
RANDOM TIP:
---------------------

If your game is crammed with large music files, find an MP3 compressor. I'm not sure if I'm allowed to give you the link, so I'll just tell you the name of the one I used, which works really well and is completely free! It's called MP3 Quality Modifier 2.2. I tried it using the "lowest quality settings". It reduced by 4,050kb file to just 1,041kb! If I'm being honest, there was not much difference in the sound at all, except this little "umph" which happened around 1 second in on each song, but it was no biggy, and there were far louder "umph" problems on the Nintendo64, which occurred a few times rather than just in the beginning. Remember, you can still select the other 4 options, but they may not reduce the file size as much.

WARNING: When you play the songs in Windows Media Player after compression, they sound brilliant, considering how small the files are. However, when you put them into scratch, for some reason the quality plummets and they sound terrible. Plus, one of my songs (I haven't got around to testing them all yet) will only play a little section in scratch, and stops. Yet, on Windows Media Player the whole thing works. I will go to FAQ and All About Scratch to see what anyone comes up with.

------------------------------------------------
INTRODUCTION/PROOF IT WORKS
------------------------------------------------

Generation:3000 The example project I will mention throughout this guide. I hope it is as useful as it is entertaining (for those who get it working online).

I decided to let everyone know how to make 199 sprites and over 1000 scripts run so smoothly that when you put turbo mode on it is intolerable and you have to have it on normal speed.

Usually, an adventure game would have a level with 10 sprites running at the same time, then on level 2 they would be recycled. The speeds are usually good, because you only need a few on stage at a time. However, a buildings game has to showcase almost everything in one go. Out of the 199 sprites on this project, only about 21 of them show in the menu and are "switched off" afterwards, the rest are all functional throughout the rest of the game AT THE SAME TIME.

Some people may recall when I first made this game, and that it worked SERIOUSLY slow. Especially during driving and disaster modes. But to show you how powerful this technique is, you will see that whilst you are driving in the refined version, 97 tiles are moving constantly. Whilst the little car in the middle is spinning around as you go along, the other 96 land-tiles are all keeping together and moving at incredible speed- that's 96 tiles! They react quickly and enable a smooth experience that just push the technology of the scratch program to it's limits. If you don't believe me, then:
Either drive a "modern" car (requires you to lay down roads first) or:
+Load it up
+Press P for cheat mode
+Add loads of money (until you have 150,000)
+Enable all research
+Build a hover car factory
+Drive one of these magnificently fast beats!

You will see how the tiles flow and all miraculously keep together. Yes there are small gaps, but some tiles overlapped, and would cause you to build double instead of once, so the 000000GridScale variable was reduced (See section three).

An interesting thing you may find is that the Sports Car reduces the speed of the game far more than the hover car does. I do not know for sure what this problem is, I am trying to investigate and sort it out now, but the only difference between the scripts on both cars is that because the hover car can fly anywhere, it has no colour detection attached to it. However, the sports car can only be driven on the roads, and because roads are not sprites, it instead detects the colour of the road. I believe that because colour detection is a "slow-script", it takes longer for scratch to do, which means that by having it there is creates lag. Either that, or the scratch cat is in a mood with me.

----------------------------------
MAKING GAMES FASTER
----------------------------------

The player's experience is very important. It deciphers whether your project gets front-paged or not, and how many fans you will get. One key thing is: never use forever statements unless it has forever. Apparently block-images have been banned from the forums, so this might be harder to explain.

EXAMPLE: CITY TILES
Outcome
   We want it so that every time the player scrolls the map, the tiles move. We also want it so that when the time changes from morning to afternoon ect., it will change it colour appearance.

Bad Way
   We could set it to [forever: if (time = morning (set colour to 50)) set x (xpos + scrollX)). That would mean that 96 sprites are checking every 0.0000001 seconds whether it should change it's colour and location. However, scratch would not be able to cope with this, as you can imagine.

Good Way
   What about:
_________
|Forever
| If time=morning
|    set colour to 10
|------------
| Repeat until time not = morning
|  If not Scrollx + x = xposition or Scrolly + y = yposition then
|     go to: X + scrollX and Y + scrollY
|----------^
| End If
~~~~~~~~~

By putting "repeat until not time = morning" it constantly refreshes the positions, but not the colour, and colour is one of those things which slows scratch down a lot. Also, by only making it check when the position does change, it means it checks only when it has too, meaning that the game is faster when it is doesn't have to be slow. You maybe be thinking, "But what happens when it is used?" Surprisingly this does work, as seen before with the drive mode. It may look like a little red or blue dot on the screen, but there has been a hell of a lot of programming involved to speed everything up, never mind to get the car working.

EXAMPLE: MENU BUTTONS
Outcome
   We want the menu buttons to behave and animate only when the main menu is on, and to switch off when not needed.
Solution
   This is where a mode system comes in handy. It is used more often in adventure games like my Pander's Quest project. A building game is divided into two main modes: menu and game. An adventure game does not have to be divided into modes per level, a mode could just be a loading screen or a cut-scene. These are brilliant to make sure that things don't over run when they're not meant to.
   What you would do is, instead of using a "forever if mode is <5 show and do stuff" (presuming that the menu takes up 4 modes to run, and mode 5 is the start of the game) you would use "repeat until mode >4". I doubt we will need the main menu back on until the game is restarted, so we can simply make it do nothing after the game is set-up.


---------------------------------------------------------
TIPS ON MAKING PROGRAMMING FASTER
---------------------------------------------------------

One thing you must remember. Having hundred of broadcast messages just messes up and slows down development time and also the project speed in some respects (a few milliseconds maybe lost at the most). I thought that's how I'd start this section off.

Looking from the development point, you know that if you use a broadcast message, then everything that responds to that message has to react quickly. However, they do not do the action until after they receive it. However, if a variable is changed then the brilliant thing about that is it can be used in the middle of a script. Instead of having one script as: forever, do animation. script two as: when i receive "blah" hide. (this means that even while the sprite is hidden it is still running, which could make a blank canvas start lagging because of all the stuff behind-the-scenes) Also, all you have to do is type in the outcome of a variable, whereas if you have hundreds of broadcast messages in one project, then it's goanna take a long time to look through them.

   Great tip on making layers of objects and keeping variables in position:
If you have a project that is complicated (such as my Panders Quest game), then you might want to use the 1,2,3,4,5,6,7,8,9,0 code. Generation:3000 uses the S,D,F,SPACE code, which has 4 layers rather than 10. Decide which one you will remember better, and read on. Any variable needs to appear when the SPACE key is pressed. This is so that when you next load the project, the variable is in the right position. S,D,F,SPACE are all layers (1-0 are all layers if you use that system). Here's what you need to do:
EXAMPLE
   Outcome:
I want a house on a landscape, with the variable that shows the time to stay in the top-right of the screen. The landscape will be part of the background, but the sky will be a sprite because I want it to have moving clouds. Finally, I want to have a dog laid outside of the house. How do I make this organised?

   Solution:
The object furthest back is the sky. So, give this sprite a script saying "When S pressed go to front". This means that when S is pressed, it will go in front of the house and the dog.
Now, give the same script to the house but with "When D pressed go to front". Now when we press S,D, the house is in front of the sky. However, the dog and the variable is missing. Do the same with the dog but give it an F. Finally, the variable needs to be in front. ALWAYS PUT VARIABLES AT THE HIGHEST LAYER. If you are using the 1-0 code, work backwards, because as long as you press the keys in the correct order, it doesn't matter how you code them. So, instead of starting with the sky, you'd start with the variable. Give this "0". Next, the dog, then the house and finally the sky. If you know something won't overlap, then put them on the same layer.

   Organisation Tips:
On my Generation:3000 game I never show the variable names on things like the budget window. Instead, I use an orange box with the number in the middle. This is so that the player cannot see the dreadfully long name for that variable. First, I grouped them together. Some had either a 1,2,3 or 4 next to it. Anything which I was only going to need once and never use again began with a Z, and the more Zs it had, the further down it went on the list. For number 1s, I used it for things to do with finance like "1ResTax". 2 was used for general statistics like "2health" and "2education". Finally, anything with 000 ect was used for things which should appear near the top of the variable (or messages) list because either I am working on that section at the moment, or they are very important.

Another tip, you can reduce the number of sprites you use by recycling them, saving quite a bit of time and space.

when [options/back v] clicked
if <(costume#) = [1]> //Costume 1 is options and costume 2 is back.
broadcast [options v] //or whatever it does
switch to costume [back v]
goto the right place
else
broadcast [title v]
switch to costume [options v]
goto the right place
end

-------------------------------------
TIPS ON GLITCH HUNTING
-------------------------------------

One of the main differences between a linear (action/adventure) and non-linear (building) agme is that a linear game requires the player to go from A to B. So, if a player notices a glitch, most likely the programmer would have played on the same path and noticed it too. However, building games have an almost unlimited number of different outcomes.

First things are first, when making a building game, have LOTS of information screens. You'll notice on mine I have budget, tourism, general and population statistics. It saves time having to keep a notepad in front of you, and checking whether the right amount of money has been added/subtracted from the beginning amount, because all you have to do is read the number on the screen and it should be that amount it's changing the cash by. So, if income = 5, then my cash should increase by 5. Simple. If you don't have an info screen, you first have to count how many buildings you've placed, and then work out what that income would be, and finally see if the game has changed the cash amount. This works for any variable with numbers. Plus, it makes your game look fancier with information screens, when in real life, it's making you lazier!

Last edited by Borrego6165 (2012-04-10 13:07:09)