7 Days to a Game ~ Day 4! Testing / Bugs / Variables

  Today was a bit of a productive day but I didn’t make much progress that would look very cool. Sometimes you need to learn new skills and screw around behind the scenes. As mentioned previous we want to have Happy shrinking when you slap him. It’s cold and this is just something that happens – don’t laugh.

  I’ve also been playing around with character speeds and I – think – that I’ve hit where I want to be. To put things in simple terms I’m having him moving at a speed of 6. I believe that is how many pixels per second that the object moves. I am going to take a moment to double check that information but for you this will be instant!


  I was unable to verify but let it be known that 1 is “very slow” and 10 is “screen tearing nausea inducing madness!” This is why I chose 6 because its nice and fast but not fast enough that it will cause you to hurl as 10 nearly has done me.

  We ended the post yesterday on objects and events. Since Happy is the protagonist we were naturally going over his events. I’m going to cover some of the highlights of the project as far as happy is concerned and the plans for tomorrow! As always I’ll have an “updated” version of the game at the end of this post. The differences are pretty simple. He now slows down by about 1% when you touch him and he speeds up by about 2% every few seconds and whenever he hits a wall. He also shrinks by 1% anytime you click on him with a minimum size of 90% smaller than his original girth.



  You’ll notice that the image has slightly changed from yesterday! We have a new friend floating around in game maker. “Execute a piece of code”.

Oh shit homey…I think he’s doing raw code.

Hide the gin and juice!

  Damn straight. I was becoming greatly annoyed by a few problems and decided to dive into the world of hard coding. You might be wondering what deep dark secrets lie within that file.

  Just what kind of super awesome amazing secrets lurk!

  Could my world change!? Has he generated the text to end nations and cull all life?!



  Well I don’t know for sure? But probably not.

  This simple line of code could actually be on a single line but I realized I could improve my productivity by spreading it across 3 lines. That’s KR Game development in action people! I learn from the best.

  We are setting the trait “speed” for the object of happyhappy to 6 as mentioned earlier in this news post. You can make up your own variables (which I will have to do soon) but this is not one of those cases. When making global variables I believe the only change is you replace the prefix target with global. So it would say global.speed=6;. But I’m probably talking out my ass so take that with a grain of salt until I prove it in action.

  The next line of code to run during the “Create” event is an Alarm. I’m going to explain alarms to you now better than any guide I was able to find through Google.


  You already know what the Applies to section relates to because you are awesome and read my post yesterday (links at the bottom of this post).

  The number of steps is just how many frames you want this alarm to take. Think of it like a bomb clock. You are setting the timer and it starts ticking back from whatever you’ve entered. But don’t forget some simple math! The amount of seconds in a step is equal to the frames per second in your game! A 30 FPS game covers 30 steps every single second.

  So how long is 120? Did you say – you did! 4 seconds! You got that without any coaxing from me. So damn proud. You are going places.

  in alarm no simply means “which of our allowed alarm instances do you want this timer to be set?” In scripting the first value is often 0 instead of 1 (although to be fair rulers and the number line both start at 0) so we’ve chosen Alarm 0. It will be coming back in a few minutes for me and a matter of seconds for you. [Relative has no point in the first alarm for reasons stated yesterday.]



  This looks familiar but confusing too! What’s going on there?! No…not there. You see it right? What is that damn madness?!


  If you recall we set a variable in the create action of Happy. It set “obj_happyhappy.speed” to “6”. So now the game is asking us what speed we want and we are responding – Bro, look. We said 6. Don’t make this weird.

  You are probably asking yourself why I didn’t just put 6 there and make this easier. Keep those panties loose [or don’t I won’t fight you.] because we’ll be getting to that in a bit!

  Also make note that we are no longer using “relative” speeds because we’ve taken this function by the balls and it is our pet now. We no longer suffer under its totalitarian madness and it will never again tell us that we don’t look fabulous in topaz. It brings out my eyes.


  You will recall we set an alarm to go off in 120 frames. Which means in 4 seconds after the game this script goes off. I realized that just having Happy slide until he hit a wall was lame as dirt and I couldn’t have the game being that low budget and terrible. We needed happy to zig and zag. I want this to act a lot like the real Happy. Sure you might think he’s going left but then he zigs right, then left, then right again, double right! What’s the even mean? Man I don’t know but he has done it.

  Everything I showed you earlier about fixed movement is the same here but we’ve got something slightly different. I could have done this in code but for times sake we are using their tools.


  There is a reason I’ve chosen to use multiplication to set the variants in speed instead of addition and subtraction. The problem with subtraction is that you could eventually (without scripts to protect you) hit 0 and actually go beyond it. If you’ve ever wanted to see some crazy shit you can either take a few hits of acid or you can start putting negative numbers in all sorts of values in your code.


(Mowgli I told you to watch that shit…)

  This will be especially important when we are removing speed from the target because we can approach 0 but never actually reach it which is ideal. Also because you are removing a % of the value you will remove a little less than you did the previous time so each click is slightly less effective as the one before it.

  This is important because I’ve found that the more you try to use the same tricks to make Happy unhappy the less effective they become. I believe they call that building a tolerance. But don’t take that from me I don’t even have an honorary doctorate.


  This one is simple. After the first line is run and Happy has moved we reset the Alarm but ask the game to remove 5 seconds from its total time. So next time it should only take 115 frames for him to do what he did. I was under the impression that it was cumulative but it doesn’t appear to be. I will confirm over the next day or so. I could do it quickly right now but its already 11PM and I want to get this out.

  In fact lets cover one more thing before we close shop for today because my eyes are doing some crazy stuff (maybe its all this staring at a strobing gif while I’m typing? Either that or the 4 hour long anxiety attack that has been just obliterating my chest. Who knows?)


  This is actually why we took control of the speed of the target. I got to the Change Sprite function and noticed that it sets the speed to a value when it changes. Well that sucks! I’m sure there is a more obvious way to fix this problem but this is the route I took it.

  You know what Applies to does, sprite is also very self explanatory, subimage presumably is witchcraft (or something else), and finally speed is the speed you want the new changed sprite to go. You are probably noticing that this is making the sprite look like Happy Happy. But – you might say – we already have him set to that?! Well that’s because the Events are listed in an order that does not go chronologically. So later (2 more events) we will be changing the sprite to something else! This alarm is the fix that switches it back to that Happy Happy we all know and love.

  I think that’s it for tonight. Tomorrow we’ll talk about hit detection, input functions, and what you do when a happy snowman flies off your screen at light speed and never returns. You know – normal stuff.

  My next plan is to add in Snowballs tomorrow! Each time you click Happy you will set off an alarm that will “charge” his snowballs! Once it goes off he will throw them and if you don’t click both of them before they hit you you will take 1 damage for each! 3 Hits (for now maybe more later) and its all over!

  This is why you can click him like mad today but if you do so tomorrow the game will be over. It’s all a matter of balance. Picking and choosing your moments otherwise you will be obliterated entirely. I think quite a few really pushy users learned this first hand *winkyfaceofsomekind*.

  Special Note: I’ve actually made the hit box precise because I found that the ellipse (for now) is just way too easy to click on. Happy was getting blown away. Now that he’s not moving at break neck speed it is more realistic for the user to be able to click him and even his arms. I’ve done it quite a lot. I’ve also given him (presumably if the code worked) a maximum speed of 8. He previously had a maximum speed of around 9 trillion and tracking that with your eyes caused near instantaneous nausea.

  Click here if you want to try out 1.1. I’d be curious if you get nauseous by the current speeds and size of Happy. I might increase his starting size or look into other forms of movement to ease that response. Maybe dim the background?

[ Table of Contents]

Day 3 – 7 Days to a Game ~ Day 3! Development and Testing!

Day 2 – 7 Days to a Game ~ Day 2! Art Assets.

Day 1 – Preparations

1 Comment on 7 Days to a Game ~ Day 4! Testing / Bugs / Variables

  1. Pingback: 7 Days to a Game ~ Day 5! This game has (snow)balls! | Rico Penguin

Comments are closed.