256
Engines / Re: I wanna be the Engine Seph Edition
« on: April 12, 2014, 10:20:27 AM »
I'm gonna use this engine for my contest fangame, so I'll criticize it as I go along 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
257
Video Discussion / Re: I wanna be the Barrage - Taiko Drum
« on: April 11, 2014, 06:44:06 PM »
HYPE 
258
Meet and Greet! / Re: HEY EVRY1
« on: March 28, 2014, 09:31:14 AM »
Hey, the guy complaining about how I never update my tutorials is here! Now where can I go to hide
Welcome!
Welcome!
259
Meet and Greet! / Re: Wazzup
« on: March 28, 2014, 09:30:05 AM »
Your Kappas are slightly misaligned... drop and give me 50!
And after that, accept my welcome to the forums
And after that, accept my welcome to the forums
260
User-Made Creations / Re: I wanna be the Octophobia 1.0 ver(03/25/2014)
« on: March 25, 2014, 09:06:59 PM »
I haven't played the game, but if it's using the yuuutu engine, then I can approve b
b
261
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: March 25, 2014, 06:51:34 PM »
Added a couple of boss attacks to the tutorial... I'm about to use up all the space available in those first 3 posts I reserved lol
262
Video Discussion / Re: I wanna be the Contrary - Rin Kagamine
« on: March 18, 2014, 09:44:12 AM »
Congrats! //
//
263
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: March 11, 2014, 10:08:35 PM »
I posted links to the good engines 
IMO, there's no real reason to use any others
IMO, there's no real reason to use any others
264
User-Made Creations / Re: I Wanna Beat the Mega Jump 3
« on: February 14, 2014, 04:57:27 PM »
if all you care for is "technically possible," I have a program on my computer that can simulate keypresses that I could use to test it for you
I'm not familiar with jump-cancelling though, much less "triple-jump-cancelling". I've tried many combinations using the program, and can confirm that the kid is jumping very low, but after 1000 automated attempts I haven't gotten through. Not to say that it's impossible, but nothing I've tried has worked
I'm not familiar with jump-cancelling though, much less "triple-jump-cancelling". I've tried many combinations using the program, and can confirm that the kid is jumping very low, but after 1000 automated attempts I haven't gotten through. Not to say that it's impossible, but nothing I've tried has worked
265
Off Topic / The Worst Song Ever
« on: February 13, 2014, 11:46:19 AM »
I made the worst song ever while watching TJ play crimson today. He was just playing his Slam Jam remixes, as usual, when I requested a Guy Rock + Slam Jam mashup. He checked for it, and returned from his search devastated, for he could not find it. In order to return order to the universe, I made it happen.
klazen.com/IWBTG/archive/I%20Wanna%20Slam%20the%20Jam.mp3
klazen.com/IWBTG/archive/I%20Wanna%20Slam%20the%20Jam.mp3
266
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: February 12, 2014, 04:41:49 PM »
You're supposed to have GM open to refer to as you go Wolsk but alright, I can do that fairly easily! EDIT: images now included in tutorial, at no extra cost!
Thanks for the sticky Starzor!
but alright, I can do that fairly easily! EDIT: images now included in tutorial, at no extra cost!Thanks for the sticky Starzor!
267
Gameplay & Discussion / Boshy W4 Skip Instructional Image
« on: February 12, 2014, 02:52:26 PM »
Someone posted an image of the path to take for the Boshy W4 skip a while back, and I thought I'd throw it up here for others to reference. It also explains why sometimes you can hear a strange noise during the trick
I take no credit for this! If you know whose it is, let me know so I can credit them.
I take no credit for this! If you know whose it is, let me know so I can credit them.
(click to show/hide)
268
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: February 12, 2014, 02:39:17 PM »
Yep, I'll be adding that to the tutorial next! ^.^
269
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: February 12, 2014, 02:16:53 PM »
THIS TUTORIAL IS OUTDATED! Version 2.0 can be found here
Bosses
Bosses are a very complicated subject. Previously, in stage design, it was more of a static process - you lay out everything as it's going to be in game, and then it's up to the player to navigate through your maze. Now, however, you'll be designing something that responds to the player, something that has phases and sequences, and it involves a strong familiarity with the object event/action editor.
In order to learn how a boss works, we'll make a generic one that does a little of everything; it will be up to you to extend these concepts and add your own ingenuity in order to make a boss that really stands out!
The first step in making your boss is going to be making a new object. Using the information you've learned so far, create a new sprite named sprMyBoss. We're going to use the image below for your boss. You can right-click it and save it to your computer, then load it into the sprite you just made using the "Create From Strip" option. Each half of this image is going to represent one frame of animation, and the individual images are 128x128. I promise I won't sue you for stealing my incredible artwork
Now, make an object and name it objMyBoss, assigning it the sprite you just imported. You'll want to give this boss its own room, so go ahead and make one for it. It would also be a good idea to make a warp from the start of the game to this room, so you can test it easily! You'll want to move that warp later on, of course. Check the "Changing Rooms" section of the tutorial if you've forgotten how to do that. Once that's all set up, head back to the object editor for objMyBoss and let's get to work!
Giving your boss HP
When it boils down to it, there are two kinds of bosses: ones you have to kill, and ones you have to survive. If you want an avoidance fight, you can skip this section. But for bosses that you want to shoot to kill, here's how you do it.
Add a Create event, and add an Execute Code action. Giving you boss HP is as simple as adding the following line of code:
The second line of code just makes your boss not change images from the happy to the angry face - we'll work on this later.
Alright, your boss has HP. But if you run your game, go into the room and shoot the boss, nothing will happen! Have I mislead you? No! There's nothing special about your bullets that makes them damage the boss; you'll have to set that up. In order to make bullets hurt your boss, go back into the object editor, and add a new event: Add Event->Collision->player_etc->bullet. This is a collision event, so it is fired every step that a bullet is touching your object, which is exactly what we want - when a bullet is touching the boss, damage it! So add the following code to the new bullet collision event:
The second line plays a sound named sndBossHit - this will play that iconic "thunk" sound when the bullet hits the boss. You can specify any other sound here; look through the Sounds folder in GM to see what sounds are available, or to create your own epic sound of bullets ripping through flesh!
What about the third line? Let's break it down: the first half of the line states with (other). The "with" keyword "shifts the scope" of following code. You place whatever object you want to run some code in the parentheses - "with (player)" would make the following code be ran by the player object. We've specified other, which is a GM Keyword meaning "the other instance involved in this event". A collision event involves two objects - the one whose event was triggered (the boss) and the one who triggered the event (the bullet). So we're shifting the scope to the bullet, and the following code will be ran by the bullet.
The code being run by the bullet is instance_destroy() - a special GM function which does exactly what it says - removes the instance from the game. When the bullet collides with the boss, we don't want it to collide again on the next frame, so we have to destroy it. That's what this code does.
You could run your game again and go shoot your boss, and every time you shoot it, you should see your bullet disappear, and hear the thunk sound. But when you shoot it 20 times, he doesn't die! Again, you have to do this yourself; GM won't be helpful at all
To make the boss die after 20 shots, we'll have to augment our bullet collision event. Use the enhanced code below:
The curly braces define a "code block" - since it comes right after the if statement, everything in the block will only be executed if the if statement turns out true - so when the hp is zero, it'll play the death sound and kill the boss.
NOW you can run your game kill your boss! But what good is a boss that just sits there and lets you kill him? No good at all!
Boss Movement
This section is a work in progress...
Boss Attacks
Let me start off by saying that things get real complicated here. We're going to be using a lot of coding and object editing, so be real comfortable with those before you go any further.
If you've made it this far, it means I haven't scared you off yet! very well, I shall confer to you the true meat of boss design - the attacks. In pretty much every boss fight - avoidance especially - patterns of apples and spikes fly all over the screen, while you stay alive. I'm going to show you a bunch of generic attack patterns, and will likely get a lot of flak for teaching everyone how to do the same boring stuff everyone else does... so please, only use them as a starting point for your own amazing ideas!
Before you make any of the below attacks, lets start with a little preparation. Open up the boss object from earlier and give him two events: Create and Alarm 0 (it's ok if he already has a create event). In the create event, add this code:
Also go ahead and make an object called objApple - this will be our projectile. Give it an apple sprite, and make its parent object "playerKiller" Finally, add an "outside room" event (under other) and add a Destroy Instance action (self). That's all, now let's move on to making the boss do stuff!
Your boss's projectile:
Targetted apples
Targetted apples seem to be a staple of boss fights. These are really easy to make; in fact, there's just a couple of lines of code you need to add to Alarm 0:
Go ahead and try out your boss now - and don't get Rekt by the apples!
Apple-splosions
Apple explosions (or apple-splosions (c) (tm)) are when you see a giant ring of apples fly out of miku's mouth, hand, or other uh... body parts. To make this happen, start off by making an Alarm 1 event, and in the creation event, change alarm[0] to alarm[1] so that Alarm 1 goes off instead of Alarm 0. Leave Alarm 0's actions alone for now, we'll revisit it later.
In Alarm 1, give it the following code:
Then, we start a for loop, which is a common construct in programming languages. This for statement starts with a variable named "i" with a value of zero, will loop as long as "i" is less than appleCount, and will add one to "i" every pass through the loop. The code we want to execute in the for loop is in the curly brackets {} which we'll call the body of the for loop, let's investigate that next.
The body of the loop should look really familiar; it's basically the same as the targetted apples, with one exception. Here, the direction is not towards the player, but rather is calculated differently. We start with dir equal to that random value, and increase it by 360 divided by appleCount every iteration of the loop. This ensures that we get apples equally spaced along a circle. For instance, if dir were zero to start with, we would get 8 apples with directions 0, 45, 90, 135, 180, 225, 270, and 315 degrees.
Finally, we set the alarm to go off again in one second, like in the previous example.
Well, that was a mouthful. Go ahead and try out your boss now, every second he'll blast a ring of apples at you in a random orientation!
Check back later, and I'll go over more interesting patterns if I ever get a break from making my own fangames
Thanks Wolfy
Bosses
Bosses are a very complicated subject. Previously, in stage design, it was more of a static process - you lay out everything as it's going to be in game, and then it's up to the player to navigate through your maze. Now, however, you'll be designing something that responds to the player, something that has phases and sequences, and it involves a strong familiarity with the object event/action editor.
In order to learn how a boss works, we'll make a generic one that does a little of everything; it will be up to you to extend these concepts and add your own ingenuity in order to make a boss that really stands out!
The first step in making your boss is going to be making a new object. Using the information you've learned so far, create a new sprite named sprMyBoss. We're going to use the image below for your boss. You can right-click it and save it to your computer, then load it into the sprite you just made using the "Create From Strip" option. Each half of this image is going to represent one frame of animation, and the individual images are 128x128. I promise I won't sue you for stealing my incredible artwork
Now, make an object and name it objMyBoss, assigning it the sprite you just imported. You'll want to give this boss its own room, so go ahead and make one for it. It would also be a good idea to make a warp from the start of the game to this room, so you can test it easily! You'll want to move that warp later on, of course. Check the "Changing Rooms" section of the tutorial if you've forgotten how to do that. Once that's all set up, head back to the object editor for objMyBoss and let's get to work!
Giving your boss HP
When it boils down to it, there are two kinds of bosses: ones you have to kill, and ones you have to survive. If you want an avoidance fight, you can skip this section. But for bosses that you want to shoot to kill, here's how you do it.
Add a Create event, and add an Execute Code action. Giving you boss HP is as simple as adding the following line of code:
Code: [Select]
hp = 20;
image_speed=0;What this does is create a variable named hp and set it to 20. There's no requirement to name your variable hp, we'll just use this because it's easy to remember (warning: Do not name the variable "health" - this has a specific meaning in Game Maker and your boss will probably not work right if you do that. Go to Scripts->Show Built-In Variables in GM to see the names you cannot use for your own variables). You can also use any value other than 20; quit being so demanding and just go along with it for now!The second line of code just makes your boss not change images from the happy to the angry face - we'll work on this later.
Alright, your boss has HP. But if you run your game, go into the room and shoot the boss, nothing will happen! Have I mislead you? No! There's nothing special about your bullets that makes them damage the boss; you'll have to set that up. In order to make bullets hurt your boss, go back into the object editor, and add a new event: Add Event->Collision->player_etc->bullet. This is a collision event, so it is fired every step that a bullet is touching your object, which is exactly what we want - when a bullet is touching the boss, damage it! So add the following code to the new bullet collision event:
Code: [Select]
hp -= 1;
sound_play(sndBossHit);
with (other) instance_destroy();The -= operator is a common operator in programming; it's shorthand for take the hp, subtract 1, and set hp to this new value. You could write hp = hp - 1 and it would mean the exact same thing.The second line plays a sound named sndBossHit - this will play that iconic "thunk" sound when the bullet hits the boss. You can specify any other sound here; look through the Sounds folder in GM to see what sounds are available, or to create your own epic sound of bullets ripping through flesh!
What about the third line? Let's break it down: the first half of the line states with (other). The "with" keyword "shifts the scope" of following code. You place whatever object you want to run some code in the parentheses - "with (player)" would make the following code be ran by the player object. We've specified other, which is a GM Keyword meaning "the other instance involved in this event". A collision event involves two objects - the one whose event was triggered (the boss) and the one who triggered the event (the bullet). So we're shifting the scope to the bullet, and the following code will be ran by the bullet.
The code being run by the bullet is instance_destroy() - a special GM function which does exactly what it says - removes the instance from the game. When the bullet collides with the boss, we don't want it to collide again on the next frame, so we have to destroy it. That's what this code does.
You could run your game again and go shoot your boss, and every time you shoot it, you should see your bullet disappear, and hear the thunk sound. But when you shoot it 20 times, he doesn't die! Again, you have to do this yourself; GM won't be helpful at all
To make the boss die after 20 shots, we'll have to augment our bullet collision event. Use the enhanced code below:
Code: [Select]
hp -= 1;
sound_play(sndBossHit);
if (hp == 0) {
sound_play(sndDeath);
instance_destroy();
}
with (other) instance_destroy();Here, we've added a block of code that will check to see if the hp is zero now, and if so, kill the boss. Make sure to use the double-equal-sign to test if something is equal to something; if you use a single equals sign, it will just set the variable to zero!The curly braces define a "code block" - since it comes right after the if statement, everything in the block will only be executed if the if statement turns out true - so when the hp is zero, it'll play the death sound and kill the boss.
NOW you can run your game kill your boss! But what good is a boss that just sits there and lets you kill him? No good at all!
Boss Movement
This section is a work in progress...
Boss Attacks
Let me start off by saying that things get real complicated here. We're going to be using a lot of coding and object editing, so be real comfortable with those before you go any further.
If you've made it this far, it means I haven't scared you off yet! very well, I shall confer to you the true meat of boss design - the attacks. In pretty much every boss fight - avoidance especially - patterns of apples and spikes fly all over the screen, while you stay alive. I'm going to show you a bunch of generic attack patterns, and will likely get a lot of flak for teaching everyone how to do the same boring stuff everyone else does... so please, only use them as a starting point for your own amazing ideas!
Before you make any of the below attacks, lets start with a little preparation. Open up the boss object from earlier and give him two events: Create and Alarm 0 (it's ok if he already has a create event). In the create event, add this code:
Code: [Select]
alarm[0]=1;This code sets Alarm 0 to one tick (frame) after creation. An alarm counts down by one every tick, and when it hits zero, it executes whatever you've placed inside its event. If you want to delay your boss's first attack, increase this value. Remember to base all your values off of room_speed (the number of ticks per second), so for a delay of two seconds you would do: Code: [Select]
alarm[0]=2*room_speed;Also go ahead and make an object called objApple - this will be our projectile. Give it an apple sprite, and make its parent object "playerKiller" Finally, add an "outside room" event (under other) and add a Destroy Instance action (self). That's all, now let's move on to making the boss do stuff!
Your boss's projectile:
(click to show/hide)
Targetted apples
Targetted apples seem to be a staple of boss fights. These are really easy to make; in fact, there's just a couple of lines of code you need to add to Alarm 0:
Code: [Select]
apple=instance_create(x,y,objApple);
apple.speed=6;
apple.direction=point_direction(x,y,player.x,player.y);
alarm[0]=room_speed/2;Line by line, this code creates an apple, sets its speed to 6, calculates the direction from the boss to the kid and sets the apples direction to that, and then sets this alarm to go off again 1/2 of a second later. This has the effect of shooting 2 apples at the kid every second. We have to re-set the alarm at the end to make sure it goes off again, otherwise you'll only get one attack!Go ahead and try out your boss now - and don't get Rekt by the apples!
Apple-splosions
Apple explosions (or apple-splosions (c) (tm)) are when you see a giant ring of apples fly out of miku's mouth, hand, or other uh... body parts. To make this happen, start off by making an Alarm 1 event, and in the creation event, change alarm[0] to alarm[1] so that Alarm 1 goes off instead of Alarm 0. Leave Alarm 0's actions alone for now, we'll revisit it later.
In Alarm 1, give it the following code:
Code: [Select]
appleCount=8;
dir=random(360);
for (i=0;i<appleCount;i+=1) {
apple=instance_create(x,y,objApple);
apple.speed=6;
apple.direction=dir;
dir += 360/appleCount;
}
alarm[1]=room_speed;Let's do another line by line analysis. The first 2 lines declare two variables, appleCount & dir. appleCount will represent how many apples you want to shoot; we choose 8 for now. dir will represent the direction of the current apple, in degrees. random(x) returns a random value between 0 and x, so we start off with a random angle for the apples.Then, we start a for loop, which is a common construct in programming languages. This for statement starts with a variable named "i" with a value of zero, will loop as long as "i" is less than appleCount, and will add one to "i" every pass through the loop. The code we want to execute in the for loop is in the curly brackets {} which we'll call the body of the for loop, let's investigate that next.
The body of the loop should look really familiar; it's basically the same as the targetted apples, with one exception. Here, the direction is not towards the player, but rather is calculated differently. We start with dir equal to that random value, and increase it by 360 divided by appleCount every iteration of the loop. This ensures that we get apples equally spaced along a circle. For instance, if dir were zero to start with, we would get 8 apples with directions 0, 45, 90, 135, 180, 225, 270, and 315 degrees.
Finally, we set the alarm to go off again in one second, like in the previous example.
Well, that was a mouthful. Go ahead and try out your boss now, every second he'll blast a ring of apples at you in a random orientation!
Check back later, and I'll go over more interesting patterns if I ever get a break from making my own fangames
Thanks Wolfy
270
Game Design / Re: Tutorial: Getting Started With Fangame Development
« on: February 12, 2014, 02:15:03 PM »
THIS TUTORIAL IS OUTDATED! Version 2.0 can be found here
Backgrounds
You don't wanna be the guy (heh puns again) that uses bland, pastel backgrounds in your game. So let's put something nice in here instead. On the left of the GM window, open the Backgrounds folder. One caveat before we go any further: GM considers background images and tilesets (a tileset is an image that has a bunch of smaller images in it that you use to build scenery) both as backgrounds, so you'll find them both in here.
Anyway, this is really simple, so go find an image that you like (any image will do, just get one already!). The typical room size in fangames is 800x600, so don't get an image bigger than that! (smaller is fine... for now, I guess) In GM, right-click the backgrounds folder, and create a new background. Name it whatever you like, and then click Load Background to open your image. Remember this for later, we'll make good use of it
Background Creation:
Tilesets are a little more complicated, but easy once you know what you're doing. Typically, tiles in fangames are 32x32 or 16x16 big. Here's an example of a tileset (Google "super mario bros tileset" if the link is ded): https://www.spriters-resource.com/snes/supermariobros/sheet/6211/
You can see that this person has taken the individual blocks from SMB1 and divided them up, and put them in an image for you to use. You can import this image into GM to create your own scenery with! Just create a new Background (we'll call it tileSMB1), and then Open Background like before, and open this image. This time, however, check the "Use as tile set" checkbox. You'll see a grid overlaid on the image, denoting where the tiles will be divided at. It's not correct, so we'll fix it. You can see that these tiles are 16x16, so set the tile width/tile height as 16. Looking at the top-left tile, there is no space between it and the edge of the image, so the horizontal/vertical offset can be left as zero. In between each tile there is a 2 pixel wide gap, so set the horizontal/vertical separation to 2 each. Now, you'll see a nice black box surrounding each tile, which means you're set! We'll test this out later in the tutorial.
Tileset Creation:
Having a hard time finding backgrounds/tilesets for your game? Try here:
https://www.spriters-resource.com/ Has a TON of sprites/backgrounds/tilesets for all sorts of games
Sounds
Sounds? Are we changing what sound the kid makes when he jumps? Well, no, you could do that I guess, but what we're really doing is getting rid of that awful guy rock. Yep, don't go any further until you've got a song of your own to use here. It can be hard to find music that you want, so here's a few good resources to get started:
Ok, now you've got a song, let's put it in the game! Open the Sounds folder in the GM window, right-click the music folder, and choose Create Sound (It doesn't matter that it's in the music folder, this is just to help you keep track of where things are). Name the sound whatever. I recommend you prefix it with bgm so it's easier to find later; for instance, use bgmYoshisIsland as the name for a Yoshi's Island song. You'll see this done in other areas of the game too; obj for Objects, spr for Sprites, snd for sound effects, etc.
Sound Creation:
Big Note: Check out the advanced section at the end of this tutorial to learn how to stop the music from repeating, which will instantly add 4.8 production values to your game!
Rooms
Enough screwing around. The heart of every fangame is the level designs. Everything else is just icing; without good platforming, what do you have, right? Well, young student, now you know enough to advance. Let us learn how to make levels!
On the left of the GM window, open the Rooms folder. The init folder here contains the boilerplate rooms needed to get you into your fangame, so don't mess with those for now. Instead, let's open up the sample folder, and double-click the room named "rStage01". This opens the Room Properties window, the heart of the designer. This room is actually 2 rooms in one, so drag out the window so you can get a wider view of everything, and let's explore what's going on.
Room Properties, with the Object tab selected:
Take a look at the left section of the window and you'll see 5 tabs:
One more piece of advice about room editing: You'll notice at the top of the window there are two boxes: Snap X and Snap Y. These control the sizes of the squares on the grid displayed on the window below. When placing an object/tile, if you click anywhere inside a grid square, the object is placed at the upper-left grid intersection on that square. Common values for these snaps are 32, 16, and 8; one "block" in fangames is 32 pixels high, so those are 1 block, 1/2 block, and 1/4 block sizes respectively.
So try placing some objects around in your room! Use a different tileset, get rid of those **** brown blocks! Et cetera! It's all yours now! Make sure to get comfortable with the above concepts before you move on, I assume your level of knowledge is a bit higher than "absolute noob" in the next section.
You can even do stuff like this!
Advanced Fangame Making
This section will cover common topics in fangame development, which you wouldn't easily find in Game Maker tutorials. These tutorials are specific to the Yuuutu engine; things may be different if you use a different engine, but the concepts are similar. You'll just have to figure out how each one does its thing.
Changing Rooms
Oh, you mean you're not just making a one-room long needle game? Ok, well then we'll need to teach you how to do move on once you've cleared a room. Usually in guy games, you go to the next room by walking off the side of the screen, or by jumping into a portal. To handle walking off the side of the screen, you need the "roomChanger" object (It's inside the "parent" folder). place that in your room at the point where you want to walk off, and then drag it a little further (use snap X/Y = 16 and get it half on screen, half off). Hold ctrl and right-click the object, then select "Creation Code" to get a script editor window. This code is run after the object Create event.
Placing a roomChanger:
Giving an instance it's very own creation code:
Type the following into the script editor:
The warp instance's new creation code:
Where <your room name> is the name of the room you want to go to (You set this in the "settings" tab in the Room Properties window). The roomChanger will do the rest for you, sending you to the next room, on the opposite side of the screen from where you left the last room. You shouldn't need to change it, but the actual room transition code is located in the player object's Intersect Boundary event if you want to see it.
To use portals (the warp object), do the same thing you did for the roomChanger, but put it anywhere on the screen. In the creation code, type the following (along with the roomTo from above):
Where the numbers represent the place in the next room you want to end up at. Alternatively, if you place a playerStart object in the next room, and leave out the warpX/warpY, then the kid will be placed at the location of the playerStart object (easier for putting him exactly where you want him).
Triggers
Have you noticed the purple squares and red spikes everywhere? These are triggers & triggered traps. To learn about them, open up the "free trigger" folder in Objects, and then open the freetrigger object. You'll see that, on collision with the player (the player2 object is just the kid with reverse gravity), it runs some code. This code checks if the variable "freetrigger.triggered" is equal to trg, and if not, sets it to trg. YOU specify trg (trg=1, trg=2, etc) in the instance Creation Code, and then when the player hits this trigger, "freetrigger.triggered" gets set to that.
Uh oh, there's a trap here...
Now, open up the "fall_free" object. Check its Step event. You'll see code that boils down to this: "If the object's not moving, then check freetrigger.triggered. If it's trg, then set the horizontal speed to h, and the vertical speed to v". The rest of the code just gets the spike to show up right.
With that in mind, you can place a freetrigger object on your level, and in the creation code, set trg=1. Then, place a fall_free/rise_free (etc.) object, and give it trg=1 as well. If you want it to fly to the right, set h=3. Or make it go left, slower than that, try h=-2. You can reuse this concept when you invent new traps, allowing you to use existing freetriggers for your new traps. I recommend that you don't use any of the "fall&rise" or "triggers" objects; there's nothing you can do with them that you can't do with some freetriggers.
Associating triggers and traps:
Non-Restarting Music
Did someone yell at you *cough*Paragus*cough* because your music restarts every time you die? Apparently the Eastern Fangame Community is a fan of this, but for those of us with sense, we like to hear more than the first 2 seconds of your lovingly hand-picked song
Non-restarting music in the Yuuutu engine is easy. Thanks to Sephalos for this quick tutorial.
https://www.iwannacommunity.com/forum/index.php?topic=33.msg140#msg140
Stuff you need to do:
Backgrounds
You don't wanna be the guy (heh puns again) that uses bland, pastel backgrounds in your game. So let's put something nice in here instead. On the left of the GM window, open the Backgrounds folder. One caveat before we go any further: GM considers background images and tilesets (a tileset is an image that has a bunch of smaller images in it that you use to build scenery) both as backgrounds, so you'll find them both in here.
Anyway, this is really simple, so go find an image that you like (any image will do, just get one already!). The typical room size in fangames is 800x600, so don't get an image bigger than that! (smaller is fine... for now, I guess) In GM, right-click the backgrounds folder, and create a new background. Name it whatever you like, and then click Load Background to open your image. Remember this for later, we'll make good use of it
Background Creation:
(click to show/hide)
Tilesets are a little more complicated, but easy once you know what you're doing. Typically, tiles in fangames are 32x32 or 16x16 big. Here's an example of a tileset (Google "super mario bros tileset" if the link is ded): https://www.spriters-resource.com/snes/supermariobros/sheet/6211/
You can see that this person has taken the individual blocks from SMB1 and divided them up, and put them in an image for you to use. You can import this image into GM to create your own scenery with! Just create a new Background (we'll call it tileSMB1), and then Open Background like before, and open this image. This time, however, check the "Use as tile set" checkbox. You'll see a grid overlaid on the image, denoting where the tiles will be divided at. It's not correct, so we'll fix it. You can see that these tiles are 16x16, so set the tile width/tile height as 16. Looking at the top-left tile, there is no space between it and the edge of the image, so the horizontal/vertical offset can be left as zero. In between each tile there is a 2 pixel wide gap, so set the horizontal/vertical separation to 2 each. Now, you'll see a nice black box surrounding each tile, which means you're set! We'll test this out later in the tutorial.
Tileset Creation:
(click to show/hide)
Having a hard time finding backgrounds/tilesets for your game? Try here:
https://www.spriters-resource.com/ Has a TON of sprites/backgrounds/tilesets for all sorts of games
Sounds
Sounds? Are we changing what sound the kid makes when he jumps? Well, no, you could do that I guess, but what we're really doing is getting rid of that awful guy rock. Yep, don't go any further until you've got a song of your own to use here. It can be hard to find music that you want, so here's a few good resources to get started:
- Your local music library: Maybe you've got a nice instrumental song? No? Ok, how about...
- Newgrounds: I've never used it, but apparently you can find good stuff on there. Try to find Dimrain47. https://www.newgrounds.com/audio/
- Youtube: Is there a song on youtube that you think would fit in a fangame? Use https://www.youtube-mp3.org to download it as an mp3! (Obligatory copyright warning: don't use anything that someone might want to sue you over later)
- Games: Old games make great sources of music. Try Googling "<name of a game> soundtrack" to maybe find some good music you can use
Ok, now you've got a song, let's put it in the game! Open the Sounds folder in the GM window, right-click the music folder, and choose Create Sound (It doesn't matter that it's in the music folder, this is just to help you keep track of where things are). Name the sound whatever. I recommend you prefix it with bgm so it's easier to find later; for instance, use bgmYoshisIsland as the name for a Yoshi's Island song. You'll see this done in other areas of the game too; obj for Objects, spr for Sprites, snd for sound effects, etc.
Sound Creation:
(click to show/hide)
Big Note: Check out the advanced section at the end of this tutorial to learn how to stop the music from repeating, which will instantly add 4.8 production values to your game!
Rooms
Enough screwing around. The heart of every fangame is the level designs. Everything else is just icing; without good platforming, what do you have, right? Well, young student, now you know enough to advance. Let us learn how to make levels!
On the left of the GM window, open the Rooms folder. The init folder here contains the boilerplate rooms needed to get you into your fangame, so don't mess with those for now. Instead, let's open up the sample folder, and double-click the room named "rStage01". This opens the Room Properties window, the heart of the designer. This room is actually 2 rooms in one, so drag out the window so you can get a wider view of everything, and let's explore what's going on.
Room Properties, with the Object tab selected:
(click to show/hide)
Take a look at the left section of the window and you'll see 5 tabs:
- Objects: select objects (from the Objects folder) to place in your room (like the spike from earlier!). Left-click places, right-click deletes. Read the notes at the bottom of the objects tab, right there on the screen for your convenience if you ever forget. (See above image for object tab explanation)
- Settings: General room settings, like the name (used to reference this room from within the game; the player will never see this). All you need to worry about is the name and the width/height, the other settings are advanced things you don't have to mess with until you need them. Always set the room size as 800x608 if possible, but if you need to make a bigger room for some reason, make the width a multiple of 800 (800,1600,etc.) and the height a multiple of 608 (608,1216,etc.). This ensures that it follows traditional fangame standards. (click to show/hide)
- Tiles: select which tileset to use to place your scenery in the game. If you click the text box at the bottom of the grey space on the tiles tab and select "tile01", you'll see the generic guy game blocks there in front of you. Select your tileset from earlier and try clicking on the different tiles to select one, and then somewhere on the level to place them. Right-click in the level to clear tiles. (click to show/hide)
- Backgrounds: Set the background to be displayed in the room. There's 8 background slots available for you to use, but in general, you'll only need to use Background 0. Besides being able to choose the background image, you can choose a color to paint behind the background, stretch/tile the background, and make the background scroll behind the level. Try it out with the background you made! (click to show/hide)
- Views: This determines what the player sees in your room. ALWAYS make sure to set the view correctly in any new room you make, otherwise the player can get strange graphical bugs, like the window jumping around on their screen. Just "Enable the use of Views", select View 0, check "Visible when room starts", and fill out the fields below. (click to show/hide)
- View in room: specifies what section of the room to display: X is the left side of the rectangle, Y the top, W the width, and H the height. You can see this view encompasses the right half of the room.
- Port on Screen: specifies where in the game window that rectangle is put. X is the left of the window, Y the top, and W/H are same as before. So, this view takes the right half of the room and sticks it into a 800x600 window for the user's viewing pleasure. You may be asking, "But why are my rooms 608 tall?" And that's because objects are typically 32x32, and 608=32*19. As long as the view is set up correctly, it'll be handled for you.
- Object Following: If you have a room larger than 800x600, and you want it to follow your player around as he moves, then set the player object as the object following, and use 400 for Hbor, and 300 for Vbor. Leave it alone if your room isn't gonna scroll.
- View in room: specifies what section of the room to display: X is the left side of the rectangle, Y the top, W the width, and H the height. You can see this view encompasses the right half of the room.
One more piece of advice about room editing: You'll notice at the top of the window there are two boxes: Snap X and Snap Y. These control the sizes of the squares on the grid displayed on the window below. When placing an object/tile, if you click anywhere inside a grid square, the object is placed at the upper-left grid intersection on that square. Common values for these snaps are 32, 16, and 8; one "block" in fangames is 32 pixels high, so those are 1 block, 1/2 block, and 1/4 block sizes respectively.
So try placing some objects around in your room! Use a different tileset, get rid of those **** brown blocks! Et cetera! It's all yours now! Make sure to get comfortable with the above concepts before you move on, I assume your level of knowledge is a bit higher than "absolute noob" in the next section.
You can even do stuff like this!
(click to show/hide)
Advanced Fangame Making
This section will cover common topics in fangame development, which you wouldn't easily find in Game Maker tutorials. These tutorials are specific to the Yuuutu engine; things may be different if you use a different engine, but the concepts are similar. You'll just have to figure out how each one does its thing.
Changing Rooms
Oh, you mean you're not just making a one-room long needle game? Ok, well then we'll need to teach you how to do move on once you've cleared a room. Usually in guy games, you go to the next room by walking off the side of the screen, or by jumping into a portal. To handle walking off the side of the screen, you need the "roomChanger" object (It's inside the "parent" folder). place that in your room at the point where you want to walk off, and then drag it a little further (use snap X/Y = 16 and get it half on screen, half off). Hold ctrl and right-click the object, then select "Creation Code" to get a script editor window. This code is run after the object Create event.
Placing a roomChanger:
(click to show/hide)
Giving an instance it's very own creation code:
(click to show/hide)
Type the following into the script editor:
Code: [Select]
roomTo=<your room name>;The warp instance's new creation code:
(click to show/hide)
Where <your room name> is the name of the room you want to go to (You set this in the "settings" tab in the Room Properties window). The roomChanger will do the rest for you, sending you to the next room, on the opposite side of the screen from where you left the last room. You shouldn't need to change it, but the actual room transition code is located in the player object's Intersect Boundary event if you want to see it.
To use portals (the warp object), do the same thing you did for the roomChanger, but put it anywhere on the screen. In the creation code, type the following (along with the roomTo from above):
Code: [Select]
warpX=<number>;
warpY=<number>;Where the numbers represent the place in the next room you want to end up at. Alternatively, if you place a playerStart object in the next room, and leave out the warpX/warpY, then the kid will be placed at the location of the playerStart object (easier for putting him exactly where you want him).
Triggers
Have you noticed the purple squares and red spikes everywhere? These are triggers & triggered traps. To learn about them, open up the "free trigger" folder in Objects, and then open the freetrigger object. You'll see that, on collision with the player (the player2 object is just the kid with reverse gravity), it runs some code. This code checks if the variable "freetrigger.triggered" is equal to trg, and if not, sets it to trg. YOU specify trg (trg=1, trg=2, etc) in the instance Creation Code, and then when the player hits this trigger, "freetrigger.triggered" gets set to that.
Uh oh, there's a trap here...
(click to show/hide)
Now, open up the "fall_free" object. Check its Step event. You'll see code that boils down to this: "If the object's not moving, then check freetrigger.triggered. If it's trg, then set the horizontal speed to h, and the vertical speed to v". The rest of the code just gets the spike to show up right.
With that in mind, you can place a freetrigger object on your level, and in the creation code, set trg=1. Then, place a fall_free/rise_free (etc.) object, and give it trg=1 as well. If you want it to fly to the right, set h=3. Or make it go left, slower than that, try h=-2. You can reuse this concept when you invent new traps, allowing you to use existing freetriggers for your new traps. I recommend that you don't use any of the "fall&rise" or "triggers" objects; there's nothing you can do with them that you can't do with some freetriggers.
Associating triggers and traps:
(click to show/hide)
Non-Restarting Music
Did someone yell at you *cough*Paragus*cough* because your music restarts every time you die? Apparently the Eastern Fangame Community is a fan of this, but for those of us with sense, we like to hear more than the first 2 seconds of your lovingly hand-picked song
Non-restarting music in the Yuuutu engine is easy. Thanks to Sephalos for this quick tutorial.
https://www.iwannacommunity.com/forum/index.php?topic=33.msg140#msg140
Quote from: Sephalos
If you're using Yuutu go in the room editor and right click the music object and click creation code. Then enter something similar to this:
if !sound_isplaying(song) { sound_loop(song); }
Then in the scripts folder and find killPlayer
Find and remove this line of code: sound_stop_all();
And change the line sound_play(sndOnDeath); to sound_play(sndDeath);
In the "world" object find the "Press-R" event and remove the line sound_stop_all();
Stuff you need to do:
(click to show/hide)
