I Wanna Community

Fangames => Game Design => Topic started by: klazen108 on February 12, 2014, 02:13:25 PM

Title: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: klazen108 on February 12, 2014, 02:13:25 PM
THIS TUTORIAL IS OUTDATED!  Version 2.0 can be found here (https://klazen.com/IWBTG/tutorial/dev_tutorial.html)

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:


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:

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: [Select]
image_speed = 1/room_speed;
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...
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on February 12, 2014, 02:15:03 PM
THIS TUTORIAL IS OUTDATED!  Version 2.0 can be found here (https://klazen.com/IWBTG/tutorial/dev_tutorial.html)

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:


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:

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)
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on February 12, 2014, 02:16:53 PM
THIS TUTORIAL IS OUTDATED!  Version 2.0 can be found here (https://klazen.com/IWBTG/tutorial/dev_tutorial.html)

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:
(https://klazen.com/IWBTG/images/tutorial_images/sprMyBoss.png)

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

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 :BibleThump:

(https://i.imgur.com/Rs9ewxB.gif)
Thanks Wolfy
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Kyir on February 12, 2014, 02:36:03 PM
Now you just need a guide on making bosses!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on February 12, 2014, 02:39:17 PM
Yep, I'll be adding that to the tutorial next! ^.^
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Starz0r on February 12, 2014, 03:28:21 PM
It seems this is a well-made post and it gets a well deserved sticky. :atkHappy:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: ethinthenougathorn on February 12, 2014, 03:39:34 PM
Wow, klazen, yoz are awesone guy! And if you had made this 1 year earlier, iwbt pedophile would have become a really great game :)
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Wolsk on February 12, 2014, 04:24:55 PM
Please add some screenshots to make it easier to follow. :x
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on February 12, 2014, 04:41:49 PM
You're supposed to have GM open to refer to as you go Wolsk :Kappa: but alright, I can do that fairly easily! EDIT: images now included in tutorial, at no extra cost!

Thanks for the sticky Starzor! :atkLove:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on March 11, 2014, 07:23:29 PM
You should perhaps post links to all of the available engines made for fangames.  :atkWaifu:


Also, great tutorials!  :atkHappy:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on March 11, 2014, 10:08:35 PM
I posted links to the good engines :P IMO, there's no real reason to use any others
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on March 11, 2014, 10:59:44 PM
I think Erunatyan's engine is good  :atkCry:


Nobody seems to use it.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: lemonxreaper on March 15, 2014, 09:38:10 PM
I think Erunatyan's engine is good  :atkCry:


Nobody seems to use it.

its bad.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Derpyhoovesiwbtg on March 16, 2014, 03:23:21 AM
I think Erunatyan's engine is good  :atkCry:


Nobody seems to use it.

its bad.

Why is the engine bad? I didnt use it,  but why its worse then the other engines?  :atkWut:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 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
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Zero-G on March 26, 2014, 03:22:28 PM
you could also open more threads for each category if you want.i think everyone would be cool if i sticky them since they are awesome guides so you have alot of space if needed
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on April 12, 2014, 10:14:50 PM
Alright Zero, I'll start splitting major sections out into different threads when I get a chance, so get that sticky gun ready :Kappa:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on April 12, 2014, 10:37:06 PM
Or perhaps a stickied thread linking to your threads.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Superlogan41 on April 16, 2014, 09:41:49 AM
Klazen i did some of your work for you  :atkHappy:

https://www.iwannacommunity.com/forum/index.php?topic=943.0
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: kilgour22 on May 20, 2014, 11:26:11 PM
On the topic of views, how do I get the view to follow the player after he undergoes a gravity change? I've tried a lot of different things, but I can't seem to get it to work.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on May 21, 2014, 12:31:51 AM
The view should follow the player perfectly, even if his gravity changes, if you set it up in the room editor.

If you need custom view following code (for whatever reason), you can use this (but be warned it's kinda buggy if you've got anything being draw on screen relative to the view):
Code: [Select]
view_xview=player.x-400
view_yview=player.y-300;

if (view_yview<0) view_yview=0;
else if (view_yview+view_hview>room_height) view_yview=room_height-view_hview;

if (view_xview<0) view_xview=0;
else if (view_xview+view_wview>room_width) view_xview=room_width-view_wview;

Just stick that in the draw event of an object you put in the room and it should work.

PS I recommend you make a new thread for any issue you have, it's more likely to attract attention and makes it easier for people with the same problem to find answers :atkHappy:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Denferok on May 21, 2014, 12:49:26 AM
Avoidance tutorial pls :Kappa:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on May 21, 2014, 05:43:49 PM
Once I'm done making I Wanna Get Rekt, I plan on compiling all the information I've learned from ripping and designing bosses; and there will be plenty of information on your basic patterns and how to go from there :D
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: TheGamerGuy500 on June 23, 2014, 06:18:12 PM
Hey, um... I try to load a sound buuuuut when I click play I just hear the sound of no one caring (silence)
the mp3 I loaded is good, it can play via media player so what the hell  :atkCry:
Is there like a size limit to how big the file can be before it won't even play?
It only does this with sound files that I load, not the built in ones.
If I can't do anything about that, I'll be doomed to use guy rock for the whole game D:

EDITS: I figured it out, you gotta put it in audacity and then export it. The tutorial never said anything about that  :FrankerZ:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on June 24, 2014, 03:15:01 PM
If you try to use a sound file that you bought from amazon or itunes or something like that, it tends to not work in Game Maker (DRM or something, idk). So yeah running it through audacity can strip off the DRM and let you use it. I guess this could apply to other music files as well, but I haven't had this happen to me often, so I didn't consider it important enough to add to the tutorial.
I might go back in and mention it, maybe in a troubleshooting section for common problems.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: petsson12 on December 29, 2014, 08:46:54 AM
This will be so useful when I start working on my game for the fangame contest.  :cirThree:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: RandomFangamer on December 29, 2014, 09:15:33 PM
When I try to run the yuuutu engine it brings up this:
___________________________________________
ERROR in
action number 1
of  Step Event
for object init:

Error reading byte.



Also, if I press ignore it brings up this:

___________________________________________
FATAL ERROR in
action number 1
of  Step Event
for object init:

Unexisting room number: 0

I have not messed with any of the code and can't figure out what the problem is,
does anyone know how to fix this?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on December 29, 2014, 10:17:23 PM
Did you make sure the .gmk file is unzipped and in its own folder?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: RandomFangamer on December 29, 2014, 10:43:57 PM
You fixed it!
It was just lying around on my Desktop, but it works now!
Yay! :atkHappy:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: PlainZombie on January 03, 2015, 01:00:47 PM
I'm having the hardest time sorting out drawing a boss health bar. I see there's a draw_healthbar function (separate from the Draw Health object action) but it never displays. Not sure if this is because my coordinates are wrong or because something is missing. I've tried drawing it in the room code, having the boss draw it from his code, and even using the Draw Health object. I feel like I'm missing something stupid. (My boss health is only 10)

Surprisingly, invincibility frames was easier to figure out than this haha.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on January 06, 2015, 11:58:55 AM
make sure you're doing draw actions in the draw event - all "draw" code needs to be done in that event.

For example, I just did this and it worked fine https://prntscr.com/5p7oo2

Let me know if it's not working for another reason!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: 128-Up on January 14, 2015, 11:22:41 AM
Sometimes when I load a .gmk file to test it, I get this error:


___________________________________________
ERROR in
action number 1
of Create Event
for object menuBossDisplay:

Error reading byte.


I know there was an "error reading byte" thing mentioned earlier in the thread, but I'm sure this is a different problem. Any ideas what's causing it?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on January 14, 2015, 06:24:45 PM
"Error reading byte" is an indicator that you've got some code reading a file improperly. This usually happens to me after I add lines to my save code to save & read a new value from the save file, but the save file that exists on disk doesn't have that new value in it yet. Therefore, when it goes to read that value from the file, it errors out because it's past the end of the file. Once you save to the file again the new value will be in there, so it won't error out again. Does this sound like it could be your problem? It would match your "only happens sometimes" problem ;)

If you think it might be something else, check the code in the create event of the "menuBossDisplay" object - try to figure out what it's loading, and why it might not be able to load that. Let me know if that helps any!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: 128-Up on January 15, 2015, 10:51:49 AM
I'm pretty sure I didn't change anything in the code... I have the feeling I'm missing something obvious, but idk, code's foreign to me. :P
EDIT: After deleting the save files made by the game (not Game Maker), I can start a new playthrough twice before the error kicks in again.
(click to show/hide)

EDIT 2: Okay, I fixed it! \o/ Turns out the problem was in the callMenuData script.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Græy on May 17, 2015, 07:40:04 AM
Are the non-GM based cross-platform engines?

I'm not willing to cash out $99 for GameMaker Studio's module that exports to Linux.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on May 19, 2015, 12:54:57 AM
As of now, I'm not aware of any basic engines available in any other programming languages with all the physics and gameplay worked out (and basic is an understatement - writing a game engine meant to be built upon is serious work!) If you're interested in developing a fangame without using gamemaker, but would like to get the physics right, feel free to ask questions, or research for yourself! I'd be very interested to see something like that developed ( ͡•ᴗ͡•)

On a side note, this tutorial is pretty outdated now... I need to write a new one for GMStudio now that we've got a working engine for it!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: GalacticHooloovoo on July 02, 2015, 09:51:34 PM
Hello! First of all I'd like to thank you for this tutorial! It has been very helpful! However, I encountered a problem whilst playtesting. When I turn the music off, I am able to pass through the spikes without dying. Do you know how to fix this?
Thanks!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Rad on July 03, 2015, 01:15:28 AM
What engine are you using?

Does your player die to spikes when the music is turned back on?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Anon70000 on July 03, 2015, 03:36:29 AM
Hello! First of all I'd like to thank you for this tutorial! It has been very helpful! However, I encountered a problem whilst playtesting. When I turn the music off, I am able to pass through the spikes without dying. Do you know how to fix this?
Thanks!
You're probably using Yuuutu.
Ctrl is a godmode in Yuuutu, iirc look in the scripts
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: GalacticHooloovoo on July 03, 2015, 10:25:41 AM
Found it! Thanks Anon70000! :tenKapple:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: GalacticHooloovoo on July 04, 2015, 03:42:54 PM
Oh! Also, I am unsure on something dealing with triggers. I know how to make it so that a spike will rise/fall, but I cannot figure out how to make it stop where I want it to. Can anyone help with this?
Thanks! (again)
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: lawatson on July 04, 2015, 05:47:19 PM
You can try making it follow a path and then setting its speed to 0 when the path ends (there's an event for it).

If you wanna go a step up, you can try to make it auto-create a path kinda like NANG triggers, although that might take a bit more knowledge to pull.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: bananaguy12 on August 05, 2015, 08:44:07 AM
This was very helpful, thanks :denKamilia_v2: :denMiku_v2:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: cragl3yman343 on August 18, 2015, 07:06:40 AM
I am new to the whole game design world as I am planning on majoring it in College. I would like to begin practicing and some people recommend just starting with Studio while others have said to start with Seph or Lemon. I would like some opinions on the professionals of the I Wanna Be community. What would everyone recommend?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: lawatson on August 18, 2015, 08:09:44 AM
I've been sticking with 8.1 for quite a while, and it looks like there's a lot of technical weird changes in Studio, but Studio has shaders and new functions as well as a lot more extensions on the gamemaker community, so I would suggest Studio to be your engine.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Katz on August 18, 2015, 11:52:34 AM
I've been sticking with 8.1 for quite a while, and it looks like there's a lot of technical weird changes in Studio, but Studio has shaders and new functions as well as a lot more extensions on the gamemaker community, so I would suggest Studio to be your engine.

The graphical aspect could might as well be foundational to the game's "wow" effect. IIRC a lot of the effects included in the Hotline Miami franchise were replicated in a similar fashion using Studio. Like this (httpss://www.youtube.com/watch?v=1W9KbhFf_Y0).

Studio's definitely the way to go if the engine's stable.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Derf on August 18, 2015, 12:36:08 PM
I'll be honest with you: if you're just starting out it doesn't matter all that much.

I use GM 8.0 and have done since it came out; I get on just fine with it and for the most part I don't find a whole lot is out of my grasp. You'll either need 8.1 to run the Seph/Lemon engines or have to use this nifty program (https://gmc.yoyogames.com/index.php?showtopic=505903) on the .gm81 files to turn them into 8.0 compatible .gmk files.

What lawatson is talking about with "weird technical changes" between Studio and the GM 8.0 range is that many features of the latter have been deprecated as the manufacturers of the program shifted their attention from a application that could produce windows games to an application that could produce a range of games on different operating systems and devices. Many functions in GM 8.0 are only really applicable to producing games for windows, for instance the ability to execute dos shells from within GM, so these are predominantly the ones that have been removed. The main change however is to do with something called "sandboxing", which refers to the fact that Studio is unable to save or load files outside of the games main directory which is forced into the hidden %appdata% folder; long story short, in many ways it limits file manipulation as a games producer and pares down/removes many useful functions. Here's a list of all functions that have been deprecated (https://docs.yoyogames.com/source/dadiospice/002_reference/017_obsolete%20functions/index.html), though I'm not sure how much this will mean to you. What I will say to round this point about deprecation up is that while some of these functions are cool, the vast majority did need to be deprecated as they are now useless/obsolete and not only that but if you're just beginning it's unlikely you'd be experimenting with much of that stuff anyway, so it's likely to be inconsequential.

Studio however, is imo a much better program than GM 8.0. A lot of new features are nice and useful, the gui is similar but much more user friendly and, as Katz said, there are shaders which are cool graphical effects you can find examples of on gmc everywhere. The only reason I stick to GM 8.0 is because I use some of the old functions and right now it's not feasible for me to move back to Studio even though I have used it to much success for projects in the past, including an interactive HTML5 game which is sadly no longer with us.

The way I see it is like this:

GM 8.0/8.1 & Seph/Lemon engines:

+Robust engines with a lot of community support, proper physics and nifty features.
+GM 8.0/8.1 games tend to run on a wide range of windows computers.
+No deprecated functions.
-No shaders or new functions.
-Rusty but usable GUI.
-Impossible to obtain legally unless you bought previous.

GM:Studio + Studio engine:
+Lots new functions with constant updates to software.
+More user-friendly GUI.
+Standard version is free.
-However it has a splash screen advertising Game Maker that you cannot remove.
-Good engine but not as many features as Seph/Lemon and there are complaints about the physics which can turn some people away.
-Games published this way have a tendency not to run on older windows machines.


For me the distinction comes down to this: GM 8.0/8.1 is better if your main focus is to create IWBTG games as the engines are better and there's more community support for them, but if your main focus is just games in general then GM:Studio is by far the best choice and a nice way to future-proof yourself as it's constantly being updated. I want to end this by reiterating my original statement though: if you're just getting into it then shaders and deprecated functions etc won't mean a lot to you and won't really affect your game designing process at all, so either option is completely viable and fruitful.

Hope this helps!
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on August 18, 2015, 03:54:15 PM
The latest version of Lemon's engine works with 8.0, just an FYI.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Kyir on August 18, 2015, 04:30:57 PM
There's no reason to not use GMS. Just politely request someone who has the full version to compile it for you if you can't deal with the load screen on the free version.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Wolsk on August 18, 2015, 06:15:57 PM
The reason not to use GMS is that the engine isn't complete, so the physics still have some issues.
I've been wanting to start on a fangame, but I won't until the Studio engine is improved.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Kyir on August 18, 2015, 07:18:09 PM
I haven't seen any complaints on the physics since the last big patch on them. Do you know of a specific problem with it?
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: patrickgh3 on August 18, 2015, 08:48:26 PM
The reason not to use GMS is that the engine isn't complete, so the physics still have some issues.
I've been wanting to start on a fangame, but I won't until the Studio engine is improved.

I haven't seen any complaints on the physics since the last big patch on them. Do you know of a specific problem with it?

I think walljump vines are the biggest thing that's missing. It's nice to have those, and I can understand wanting other miscellaneous stuff like gravity flippers and ladders. However, I recommend using Studio even if the current version of the KS engine is missing some features or has some minor physics inconsistencies, because _you can always add and fix that stuff later_. If a new version of the engine is released, with physics improvements or vines or whatever, you can update your game accordingly very easily.

Another plus I would like to add to Derf's list for Studio is the project structure is a lot more friendly. This breaks down into a bunch of small benefits that add up. Reusing resources from other projects is simpler than how it worked in 8.1 with resource files. Tools like my RMJ room importer (https://www.iwannacommunity.com/forum/index.php?topic=1744.0) are much easier to make for Studio, so you can use that tool and expect other fangame tools to be made. You can also use source control much more easily, though I don't expect most to use it for fangame development, it's a nice option to know about if you're considering making non-fangames in Game Maker.

Overall, Studio adds new features and fixes annoyances in 8.1. It's the future; there will only be more support for Studio and less support for 8.1 from now on, in terms of both general use and specifically for fangames.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Wolsk on August 19, 2015, 12:42:54 AM
My biggest issue with the Studio engine right now is that if you jump the frame you land like in a bhop, it uses your double jump instead of starting with a single jump.  It's pretty annoying for players who want to go quickly.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: klazen108 on August 20, 2015, 10:19:48 AM
Yoyo actually edited the player in the KS engine and fixed the physics problems, I've ported his changes over and tested it and everything (including bunnyhopping) seems to work fine now. However, he's working on his own engine, so I'm going to let him release his before I release a patch for KS, I don't want to be that guy who steals all someone's code :P

Going forward, Yoyo's engine will probably be the Yuuutu equivalent, and this one the Seph equivalent. By that I mean you'll pick his engine if you want all the basic gimmicks pre-programmed for you, and you'll pick KS if you want more of a clean slate with only the basic physics provided.

Sorry for the silence recently, I've been pretty busy with work and other projects, not enough time in the day  :BibleThump:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Derf on August 20, 2015, 10:26:48 AM
That's really good news Klazen! I can't wait for the next KS update.
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: Vitellari on October 16, 2015, 05:42:11 AM
Thx, you've helped me a lot :atkHappy:
Title: Re: Tutorial: Getting Started With Fangame Development
Post by: zaphod77 on January 20, 2016, 08:27:11 AM
some tips.

I Wanna Be the Studio Engine YoYoYo Edition uses objPlayer instead of player as the player object.

Making something (like, say, a mini Hachune Miku) chase the player is easy, simply place this is it's step event.

if (instance_exists(objPlayer))
{
direction=point_direction(x,y,objPlayer.x,objPlayer.y);
}

In the create event just set it's speed to whatever you want.

It's possible to modify all of any given object at once on the screen.  Examples include launching all of them at the player, making them all fall down, making them freeze and change color, expand outwards from Miku's hand, etc.

You can either use an alarm, or a tick counter in the boss itself to do this. the important trick is the with statement

So say you've spat out a bunch of objCherryBounceRandom.  At a certain point in the song, you want them to stop, and launch a second batch and then later make them all fly outwards.

To pause them all, you simply put in you alarm/step event.

with (objCherryBounceRandom)
{
speed=0;
}

Of course if we were to try to make it fly away, it would still bounce. this will not do. so we need to put in a hook in objCherryBounce to allow the bounce to be bypassed.

Open objCherryBounce. Add to the create event

keep_bouncing=true;
originx=x;
originy=y; ///remember where i spawned so we can fly away from there later.

and then change the Step event to.

if (keep_bouncing)
{
move_bounce_solid(0);
}


Now you can turn off the bounce feature of your bouncing cherries when you need to.

we make them fly off away from Miku's hands with

with (objCherryBounceRandom)
{
speed=6; ///or whatever
keep_bouncing=false;
direction=point_direction(originx,originy,x,y);
}

by swapping originx with x and y with origin y, it will go towards the spawn point instead.

You probably want them to change colors too. in this case, simply make a new object, say objCherryBounceRandomColorable with objCherryBounceRandom as a parent using the white cherry sprite with no events. and then when you spawn then you can

a.image_blend = make_color_rgb(100,255,100);

assuming you used

a = instance_create(spawnx,spawny,objCherryBounceRandomColorable);

to spawn it.

and when you stop them, you can also change the color with

with (objCherryBounceRandomColorable)
{
speed=0;
image_blend = make_color_rgb(10,10,10); ///dark grey
}

You can even use with to change all objects of one type into another.  Say you have a negi object that goes a random direction of left or right. (what can i say, it's a classic. :) )

with (objCherryBounceRandomColorable)
{
instance_create(x,y,objSidewaysNegi);
instance_destroy();
}

If you need to address different groups of the same object, simple make a child of it with no events.
Coding objSidewaysNegi is left as an exercise to the reader. :)

As we can see, the possibilities are limitless.
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: klazen108 on May 31, 2016, 02:01:03 AM
Over two years since I made the original tutorial... time sure flies! While the tutorial as I've written it is still pretty useful, a bunch has changed since then, like our recent move to GMStudio! In order to stay with the times, I've overhauled everything. Because there's just so much to tell, I felt that using a separate webpage gives me better control over the whole structure, so I've moved it off the forums onto my website.

Even if you're well versed in the fangame creation process, I invite you to take a look at the new and improved tutorial! There's some sections in there based on common questions I get asked from newbies and professionals alike. If you've got a question that isn't covered but think is something everyone should know, please post a reply and let me know! It's not finished yet, but since all the basics are covered, I'm going ahead and releasing it. There may be some glitches and typos (there's over 110,000 characters in the document, my fingers are tired), so let me know if you find any of those too. Stay tuned for updates, maybe more after Fangame Marathon 2016 is over...

Version 2.0 of the Fangame Development Tutorial can be found here! (https://klazen.com/IWBTG/tutorial/dev_tutorial.html)

Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: Denferok on May 31, 2016, 05:18:32 AM
Minor complaint, having like 30 words per row makes it a bit hard to read, would recommend giving the website a width of like 60% and the margin: auto of course. Other than that, thanks for your great help!
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: klazen108 on May 31, 2016, 09:29:59 AM
Thanks for the suggestion! I'm practicing my web design skills and wanted the page to look nice on mobile, so I was avoiding a set width. I've changed the layout to have a max width of 1024px, so it should still take up all the space on a small screen, while not expanding so much you have to turn your head on a large screen. Hope that helps!
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: L4Vo5 on May 31, 2016, 06:25:50 PM
Something i'd like to point out about the new version:

About the wobble effect: You can replace sin and cos by lengthdir_x and lengthdir_y. These functions are included in gamemaker and allow you to use degrees instead of radians, if you prefer. It also does the multiplication by the speed (or wobble_distance in this case) inside the function
About performance: you should advice that once you've finished the game, divisions should be replaced by multiplications when possible, to make the game a tiny bit faster. And if you're dividing by room_speed and all rooms have the same room_speed, you can treat it like that constant value.
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: Denferok on May 31, 2016, 06:59:51 PM
If you change the max-width: 1024px; to width: 60% and add this code at the bottom of the css file it'll work for mobile aswell and be scalable for larger / smaller monitors

Code: [Select]
@media(max-width: 768px){
  body{
    width: 100%;
  }
}
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: aytoms29 on May 31, 2016, 09:32:54 PM
This is some good stuff!

Good job
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: klazen108 on June 01, 2016, 12:11:17 AM
That's a pretty neat CSS feature, Den! I've added that to the stylesheet, hopefully that makes it a bit easier to read. And thanks for the tips Lavos, those are certainly some concepts I'd be interested in going into detail with.

I've also updated the tutorial to include a section on Hit Points, both for the enemy and for the kid. That'll probably be the last of the additions for a bit, I need to get to work on setting up for the marathon!
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: Kyir on June 02, 2016, 03:49:59 PM
Looking good so far! I'm going to have to start fiddling with shaders next time I have time to work on games again.
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: aytoms29 on June 30, 2016, 10:12:35 PM
Fancy dancy
Title: Re: [UPDATED] Tutorial: Getting Started With Fangame Development
Post by: infern0man1 on June 30, 2016, 10:34:07 PM
No necroposting a topic with a shit-post like that; warned.