Fangames > Game Design

[UPDATED] Tutorial: Getting Started With Fangame Development

(1/14) > >>

klazen108:
THIS TUTORIAL IS OUTDATED!  Version 2.0 can be found here

If you've ever said the words "I wanna make my own fangame" (pun intended), but have NO idea how to get started, then you're in the right place! I'm gonna try and go over all the basic information on Game Maker and fangame engines required to make your own fangame. This is by no means a comprehensive tutorial, it's just enough to get you on your feet. But after this tutorial, you should be able to start asking the right questions!

Note: screenshots of the editing process are included in the tutorial as "Spoilers". Just click the "Spoiler" button to see them!

Table of Contents:
Environment Setup: Get your computer ready to design fangames!
Learning the Basics: Try the example game provided with the engine!
Sprites: The images and animations in your game!
Objects: The actual "things"! Learn to code!
   DnD Actions: Simple and Abstract
   Script Actions: Complex and Powerful
Backgrounds: Because no one wants to play a game with a spring green background!
Sounds: Repeating guy rock? No thank you!
Rooms: The actual platforming and level design!
Advanced Topics: How the pros do it!
   Changing Rooms: For games longer than one level!
   Triggers: Who doesn't love a good troll trap every once in a while!
   Non-Restarting Music: Pretty self explanatory
Bosses: It gets serious from here!
        Giving your boss HP: So you can kill it, of course!
        Boss Movement: Gotta go fast! (not done yet :BibleThump: )
        Boss Attacks: Get Rekt! (not done yet :BibleThump: )
                Targetted Apples: Shooting at the player
                Apple-splosions: Rings of apples are dabes

Environment Setup

Alright, the first step in development is to get yourself set up with the tools you need. Most guy games (IWBTG and Boshy being the biggest counterexamples) are made using a program called Game Maker (hereby referred to as GM), from the company YoYo Games. The current version of GM is known as GM Studio, but don't go download that just yet...

A few kind developers have released "engines", or pre-made Game Maker game files, that already have all the physics ironed out for you. Unfortunately, the good engines are not made for GM Studio, but rather for an older version (Game Maker 8.1). So, in order to make fangames using these engines, you'll need to get GM 8.1. This version is out of production, so you'll have to find that on your own. We cannot provide you with a link for it. We can, however, provide you with links to the engines:


* Seph Edition: https://www.iwannacommunity.com/forum/index.php?topic=921.0

* Yuuutu Edition: https://www21.atwiki.jp/iwannabethewiki/pages/484.html

* Nekoron Edition: https://www21.atwiki.jp/iwannabethewiki/pages/337.html

* YoSniper Edition: https://kayin.pyoko.org/iwbtg/forums/index.php?topic=16549.0

PLEASE do not use any engine but the ones above. All the good players are used to these physics; using a different engine will just piss them off ;) For this tutorial, we'll be using the Yuuutu edition (for the sole reason that it's what I'm currently using; I recommend using the Lemon edition when you really get started).

So now you should have downloaded and installed GM, and have downloaded one of the engines (Yuuutu). Open the engine file in GM (unzip it first if it's in a ZIP file!). Now we can get to work!

Learning the Basics

After opening the engine in GM:
(click to show/hide)
As a beginner, the very first thing you should do is run the sample game included with the engine and see what you're about to be dealing with. Run the game by pressing the green arrow on the toolbar at the top of the screen, or by pressing F5. It will start in traditional fangame fashion, and you can test it out for yourself. Why is it so important to play the sample game, you ask? Well, it's because we'll be modifying it, and I want you to know what everything is like before our modifications so you can see the effects.

Once you've had enough fun with the sample, press "Esc" to quit and be dumped back at the GM window.

At first, the GM interface can be daunting, but it's all divided up into easy-to-grasp sections, which you can see on the left of the window. Let's walk through these sections and see what's going on.

Sprites

"Sprite" is just fancy game developer lingo for an animated image. You'll use sprites for anything that isn't part of the background, or that may move in-game (think cherries, spikes, the player, bosses, etc). If you open the Sprites folder, you'll see a bunch of subfolders, which the engine developer made for you (you can make your own by right-clicking and choosing "Create Group"; same for making a new Sprite). Open up the "random threats" folder, and double-click the "sprSpikeUp" Sprite to open the Sprite Properties window.

(click to show/hide)
The Sprite Properties window allows you to modify the sprite. Click Edit Sprite to get the Sprite Editor window. Hover over all the buttons on the toolbar to figure out what they do. We'll be making an animated spike to get accustomed to the editor, so select image 0 (the spike image), and then click the copy button (the two sheets of paper) and the paste button (clipboard with paper) to create a second image frame (yes, ctrl-c/ctrl-v works). Go ahead and check the "Show Preview" box on the left too. The image you see is animated, but it doesn't look special yet because both frames of animation are the same. Let's change one to see what it does.

Sprite Editor:
(click to show/hide)
Select image 1, and then click the pencil button on the toolbar to open the Image Editor. This isn't an image editing tutorial, so I won't go into detail, but go ahead and make something of the spike. Do whatever you want, I'll wait for you ;) Once you're done playing with the image editor, click the green checkmark button at the top left to save the image.

Image Editor:
(click to show/hide)
Back at the sprite editor, you should see a rapidly-flashing animation of your new spike on the left. Change the "Speed" from 30 to something lower for a less epilepsy-inducing animation (like it says, this speed is only for the preview, we'll correct this in-game later). Press F5 to start the game, and go find a spike. You'll see it flashing like crazy. Be proud! You've just made your first animated spike, and are well on your way to crafting your own HD Spikes :) We'll fix the crazy flashing in the next section, Objects.

Already have some images you want to put in your game? Try File->Add From File. Got a single image with multiple frames of animation that you want to split and add all at once? Try File->Create From Strip. Anything else you'll have to Google for help; that's beyond the scope of our tutorial.

Create From Strip:
(click to show/hide)
Objects

Objects are the actual "things" in your game. They use sprites as their images, and their behaviour is determined by code you write (don't freak out just yet!). We just edited the sprite of the upwards spike, so let's open that object to fix the animation flashing. Open the Objects folder, then the generic threats folder, and finally double-click the spikeUp object. You'll get the Object Properties window, much like you got the Sprite Properties window when you double-clicked the spike sprite (see, it makes sense!).

(click to show/hide)
On the left, you'll see a bunch of parameters for the object:

* Sprite: allows you to specify the sprite for the object. Clicking the name "sprSpikeUp" will bring up a list of sprites you can change to, but don't do that here.

* "Visible" and "Solid" checkboxes: determine if the object is visible and solid when it is first created in-game.

* Depth: determines the drawing order, with high values at the back, and low numbers in front (negative numbers are allowed). The depth of this spike is 10, which means that anything with a depth of 11 or higher shows up behind the spike ingame, and anything with a depth of 9 or less will be in front of the spike.

* Persistent: basically means "keep this object alive even if you leave the room", don't check this unless you have a very good reason (you don't).

* Parent: Specifying a Parent object makes this object "inherit" all behaviour from the parent - you can see here the spike is a child of "playerKiller"; any child of playerKiller will kill the kid on contact (playerKiller itself is an object in the engine - you can go look at it for more information).

* Mask: The mask allows you to specify a sprite which acts as the "collision box". For instance, if you create a spike that isn't the exact same size as a regular spike, but want it to act exactly like a regular spike, use a regular spike sprite for the mask. You typically won't need to do this though.

The real meat of the object editor is in the Event/Action lists. This allows you to specify behaviour for the object. It's a cause & effect system: when an "event" happens, it performs a set of "actions". On the far right, you can see all the actions you can perform. It'll take a while, but you'll learn them if you keep trying. All of these are known as "Drag and Drop" actions, or "DnD" (helps to know this when you're Googling for help). For more advanced control, you'll need to actually write code. We'll fix the spike animation using both DnD and code, so you can see both in action.

But first, I want to make a small note about terminology. When talking about objects, you'll often hear the word "instance" used. You may not know what that means, or at least not what it means in programming lingo, but it's real simple. Think of an "Object" as a prototype, or blueprint, or set of instructions, from which you can create any amount of "Instances". GM gives you a special section to code for each individual instance, called Instance Creation Code. For example, if you have a moving platform that can go anywhere as the object, in the instance creation code you can specify the direction and speed for that particular platform. We'll revisit this topic later in "Rooms".

DnD Actions

Back to fixing our spike. First, we need to specify an event. We want to specify an "animation speed" for every instance of the spikeUp object. How can we do this? Why not have the game do it every time it creates an instance? Add a Create event with Add Event->Create. Now, select the Create event. The Actions list on the right now lists all the actions that happen at instance creation (none yet!). Click the "main1" tab on the right, and drag the "Change Sprite" action (the red Pacman) into the Actions list. In the action properties window, select the sprSpikeUp sprite from earlier, leave subimage as 0 (remember image 0/image 1 from the sprite editor? This field specifies which image we start at), and for speed type this exactly: 1/room_speed

Sprite Change Action Window:
(click to show/hide)
Technical information warning! "room_speed" is one of GM's built-in variables. Its value is the number of "ticks", or updates, that the game performs per second. You should never need to change this, but in the Yuuutu engine, it's 50. The "speed" is added to a counter behind-the-scenes every second, and the value of this counter determines which image of the sprite is to be drawn. This means that every "tick", 1/50 is added to the image counter, and since 50 "ticks" happen per second, the counter increases by 1 every second. If the counter goes past the number of images in the sprite, it just goes back to 0 and keeps going. So we get animation at one frame per second!

That's all you have to do to fix the animation! Go start the game again, and look at the spikes. Every second, they'll switch back and forth between the images you made in the sprite editor. If it's too slow for you, try raising the speed (2/room_speed would be 2 frames per second, 3/room_speed is 3, etc.) Also try adding more animation frames to make it look cooler!

Script Actions

Ok, that was the drag-and-drop tutorial. But for anything interesting, you'll need to delve into the code... so you might as well learn now! Code is added to actions just like the other DnD actions; go to the "Control" tab in the Object Properties window, and drag the "Execute Code" action (the piece of paper) into the Actions list. Brace yourself, because it will immediately open the Execute Code script editor. Luckily, all we are trying to do here is fix the image speed, so it'll take just one line of code. And... here... it... is:


--- Code: ---image_speed = 1/room_speed;
--- End code ---

Execute Code Action Window:
(click to show/hide)
Not bad, huh? Notice how the words "image_speed" and "room_speed" are both red? That means GM recognizes them as special variables, like I mentioned before. There will be a red highlight to the left of the text if you messed it up, so make sure you copied it exactly! Hit the green checkmark to save the script, and then, back at the Object Properties window, click the old DnD action in the list, and press the "Del" key to delete it. Now, there's only code controlling your object; let's go see how it does. Oh, what's that you say, it worked great? Good. Well, that's all I have to tell you about scripting, but PLEASE go read the GML (Game Maker Language) Reference at https://docs.yoyogames.com/source/dadiospice/002_reference/index.html to learn more about GML, the functions and variables you can use, and what you can do with it.

Tutorial continues in next post...

klazen108:
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:
(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.

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: ---roomTo=<your room name>;
--- End code ---

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: ---warpX=<number>;
warpY=<number>;
--- End code ---

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();

--- End quote ---

Stuff you need to do:
(click to show/hide)

klazen108:
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 :Kappa:


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: ---hp = 20;
image_speed=0;
--- End code ---
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: ---hp -= 1;
sound_play(sndBossHit);
with (other) instance_destroy();
--- End code ---
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 :Kappa:

To make the boss die after 20 shots, we'll have to augment our bullet collision event. Use the enhanced code below:

--- Code: ---hp -= 1;
sound_play(sndBossHit);
if (hp == 0) {
    sound_play(sndDeath);
    instance_destroy();
}
with (other) instance_destroy();
--- End code ---
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: ---alarm[0]=1;
--- End code ---
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: ---alarm[0]=2*room_speed;
--- End 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:
(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: ---apple=instance_create(x,y,objApple);
apple.speed=6;
apple.direction=point_direction(x,y,player.x,player.y);
alarm[0]=room_speed/2;
--- End code ---
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: ---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;
--- End code ---
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 :BibleThump:


Thanks Wolfy

Kyir:
Now you just need a guide on making bosses!

klazen108:
Yep, I'll be adding that to the tutorial next! ^.^

Navigation

[0] Message Index

[#] Next page