Hey Rad, glad to see you're back again :~)
In order to manipulate the size of an object you'll need to know about two values called "image_xscale" and "image_yscale" which control how big an object is comparative to its original sprite size on the respective axis (e.g. if you want a spike to be taller than normal you would increase the image_yscale value, if you want it to be wider then you'd increase the image_xscale value and if you want it to be bigger or smaller proportional to its normal size you need to increase or decrease both at the same increment). Two things to note about this though: the default all objects have these values set to is 1, so setting it them both to 2 would make an object two times the size it normally is and 0.5 would be half. The second thing to note is that object size and orientation manipulation all happen relative to its origin point as set in the sprite (the little crosshair) so its often best to have the origin of the sprite centered or else manipulation can look weird.
You don't just have to set these values either, you can use them like any other variable.
if(image_xscale < 3){
image_xscale += 0.25;
image_yscale += 0.25;
}
That code would gradually increase the size of an object until stopping when it was 3 times as big as it normally is. If you set a trigger with this you should easily be able to get to results you want.
As for triggers, I don't tend to use them all that often as I'm not a big fan of the trial-and-error approach you speak of, however for one of my latest games I did write an incredibly rudimentary trigger system to start and stop triggers which you might find useful. I'll say now that it's very limited, but I hope you find some use for it.
Create Event:
ypos = y;
move = 0;
Here we initialise two variables. "ypos" which is my shorthand for "y position" which we set to the object's starting y position; we need this because we want the trigger to stop when it gets a certain distance from its starting point, so having its starting position recorded is essential. "move" which is boolean variable (this means it's either a 0 or a 1, or a true or a false) in which 0 means it's stationary and 1 means it's moving.
Step Event:
if(collision_rectangle(x-8,y,x+40,y-608,player,0,1) && move = 0){
move = 1;
}
if(move = 1 && y != (ypos-dest)){
y -= 8;
}
else if (move = 1 && y = (ypos-dest)){
move = -1;
}
if(y < (ypos-dest)){
y = ypos-dest;
move = -1;
}
Ok, so here is the meat of the code. I'll run through it bit by bit. I'm just going as thoroughly as I can, so sorry if any of this is patronising, it's not my intention! :~)
"if(collision_rectangle(x-8,y,x+40,y-608,player,0,1) && move = 0){
move = 1;
}"
Okay so what this does is create an invisible collision box around the object. Since the spike sprite is 32 pixels wide, I have set this to create a box that is 48 pixels wide; an extra 8 pixels either side of the main 32 pixels so you can activate the trap by baiting it, this is achieved by the x-8 and x+40 in the code. That covers the width of the collision box, but the height is essentially just anything above the spike. So what this part of the code is doing is saying that if the player enters this collision box and the spike is not moving, set the move variable to 1 and therefore make the spike start moving. "&&" just means "and" so the code is checking if both of these conditions are true before proceeding, you can actually just write "and" in game maker instead of two ampersands and it will do the same thing but I prefer "&&".
"if(move = 1 && y != (ypos-dest)){
y -= 8;
}
else if (move = 1 && y = (ypos-dest)){
move = -1;
}"
This next part handle the movement and introduces two concepts which are important to learn in general, but will help a lot with triggers; I'll get onto these as they come up. The first part concerns making the object move, and the second part making it stop at a certain point. The first part says that if move = 1, e.g. the spike is in its moving state, and the spike's y coordinate does not equal the starting position "ypos" minus the destination "dest" the spike moves up by 8 pixels ("!=" means "does not equal", you can also write "<>" if you'd prefer). Now, you might rightly be saying "but we haven't set the 'dest' variable anywhere, have we?", and you'd be correct, we haven't set it in the object's main code. This is the first of two things that is useful to know in game maker:
In the room editor you might have noticed that there's more you can do than just add and delete objects. If you hold down the control key and right click any object a little menu pops up. Right at the bottom is an option called "Creation Code". This is a powerful feature to learn how to use. What it does essentially is add extra code to the creation of an object in the room, but it only effects that one instance of the object and not every other instance of the same object in the room. This means, instead of having to make 10 different triggers with different destination values, you only have to create one and add the value you want to each in the room. For instance, if you only wanted a spike trigger to move up by 64 pixels you'd open the creation code on that specific spike and add this to the code:
dest = 64;Now the second part of this code essentially says if the spike is moving and it's at its destination point, set the move variable to -1. Now again, you might be thinking "but Derf said earlier it was a boolean variable which is either a 0 or a 1, and now he's setting it to a -1? What gives?", and again that would be a good question. What I'm doing here is setting it to what is known as a rogue value (or a sentinel value, or a dummy value, in case you read about it somewhere else). This is the second thing that is useful to learn about not only for Game Maker but for coding in general. What this is, is a value that terminates the process as there is no code which will activate upon the variable being set to this value, so it will stay there forever. By setting move to -1 we're not just saying "the spike will now go back to its stationary state", we're saying "the spike will now remain in its stationary state forever". This is because the spike is at its destination but the player might still be in the collision box and we don't want it to trigger again.
"if(y < (ypos-dest)){
y = ypos-dest;
move = -1;
}"
This is the last part of the code and essentially just makes sure that the spike doesn't for some reason over shoot its mark by setting it to the destination if it does. (Since the spike moves at -8 pixels on the y value per step, if you set the destination to something that is not a multiple of 8 it won't line up correctly and we want to avoid this).
As I said, this code is far from perfect. The flaws with it include: it can only be triggered once, so no fancy retriggering can be achieved; since the collision box takes up all the space above it, it will trigger even if it's at the bottom of the screen and the player is at the top; it can only be triggered by being near it, so you can't trigger it from far away. But the the main pros for me include that you only need one object for each of the four directions (the code I gave you only moves upwards, but you should easily be able to reconfigure it for moving down, left and right), that you don't need separate trigger objects to set it off and most importantly that its code is relatively simple.
I hope I didn't miss anything here, I'd be happy to answer questions if something didn't make sense.
Something worth doing, as anon has alluded to, is going through different engines and learning their different approaches to things. While I think Nikaple handles funny and is cluttered, it has a lot of interesting things you can more or less just steal without having to edit much to fit into other engines. Yutuuu is another engine I wouldn't recommend actually using, but is worth looking at the internals of to observe coding and steal some of the extra things it includes. You shouldn't pass over more streamlined engines such as Lemon (personal favourite) or Seph's engine as their code may be easier to understand and you can learn a lot from how neatly they handle things.
Honestly, I learnt from working on fangames. I know it's trite and I know it's what you expected to hear but working on games really is the best way to get better. My two main jolts in my game making experience were: working on I Wanna Be The Sublime and getting to delve into the GMK of someone who was far my superior with coding and just getting to tinker with things & secondly working on my current game and pushing myself to not give up when I couldn't work out how to do something but instead search the internet for how to fix it. I haven't personally checked this out but I assume it would be helpful,
Sephalos' Super Kid Bros. 3 Source Code. Looking at other people's code is 100% one of the best ways to learn as I mentioned.
I hope some of this helped :~)
Topic: Need help with traps, and something to help in my gamemaking future (Read 3033 times)