Save-Point - Tutorials

Ruby's Peculiarities

Sat, 13 Sep 2025 04:54:14 +0000

Ruby's Peculiarities

by Kyonides

This thread is all about some strange or unusual or certain features specific to the Ruby programming language. Some are object-oriented or functional characteristics while other are just internal specifications you should know about. This is NOT intended to go too deep into any of the topics discussed here. There's another thread that focuses on analysis of Ruby and RGSS here on the board.

NOTE: Parent class and Super class are synonyms here.

Index

It has 5 Types of Variables
CONSTANTS are NOT as Static as their Counterparts in other Languages
Classes and Modules are ALWAYS OPEN
You only declare a class's parent class ONCE.
The Very Existence of the Eigenclass or Metaclass in Ruby
Modules have other ways to define NEW methods without explicitly specifying they belong to that module
Ruby's Boolean Values

1. It has 5 Types of Variables

Content Hidden

2. CONSTANTS are NOT as Static as their Counterparts in other Languages

Content Hidden

3. Classes and Modules are ALWAYS OPEN

Content Hidden

4. You only declare a class's parent class ONCE

Content Hidden

5. The Very Existence of the Eigenclass or Metaclass in Ruby

Content Hidden

6. Modules have other ways to define NEW methods without explicitly specifying they belong to that module

Content Hidden

7. Ruby's Boolean Values

Content Hidden

Creating Platform Games (GameMaker)

Tue, 27 May 2025 17:08:53 +0000

This article was archived in February 2002
when GameMaker 4 was released.
I probably snagged it at GamingWorld
Yet concepts should still hold.

Creating Platform Games
Copyright 2002 by Mark Overmars
New version based on Game Maker 4.2

Platform games are very common, in particular on devices like the Game Boy. In a platform game you look at the scene from the side. The player normally controls a character that walks around in the world. This world consists of platforms. The player can walk on these platforms, jump or drop from one platform to the other, use ladders or ropes to get to different places, etc. On the platforms there are objects to collect, enemies to avoid or kill (often either by shooting them or by jumping on top of them), switches to press to open passages, etc. Also the player normally requires skill to jump over dangerous areas. In some platform games you see the whole level at once, but in most you see only a part around the character. In such a case, finding your way around becomes an additional challenge.

Creating a good platform game is not trivial, also not with Game Maker. There are three difficult aspects:

Creating a natural motion for the character.
Creating enough variation in monsters, background, etc.
Carefully designing the levels such that they are fun to play and get increasingly difficult.

In this tutorial I will give some advice and tricks about how to create platform games using Game Maker. The tutorial requires that you have version 4.2 of Game Maker or later. The tutorial is accompanied by a number of demo games. These are not full games. They consist of just one level to demonstrate some particular aspect. You can use them as a basis for your own platform games.

The basics

We start with the most simple platform game. You can find it in the file platform_basic.gmd (ATTACHED). In each platform game there are two basic objects: the character controlled by the player, and a block object that is used for the floors (platforms) the player can walk on and the walls that the player cannot pass. We need two sprites: one for the character and one for the block. For the character we use a simple ball. For the block we use a (non-transparent) black square. We create two objects: a solid block object with the block sprite and a character object.

Horizontal motion

We now need to define the motion of the character. The problem is that the character must walk on top of the floors. It must not intersect the floor. If the character jumps or falls off a platform it must land correctly on the next platform. There are a number of different ways in which the character can walk, jump, and fall. Different platform games use different modes. Normally we just use three keys to control the motion. The left arrow key should move the character to the left, the right arrow key should move it to the right, and the up key or the space key makes it jump.

Let us first consider the left and right motion. The first choice to make it whether the player can only change its direction of motion while on a platform or also in the air while jumping or falling. Even though the second option is not natural (it is rather difficult to start moving left while you are falling down) is tends to lead to nicer game play and is actually also easier to implement. The second choice is whether the motion has constant speed or whether it accelerates when you keep the key pressed. We will opt for the first choice. Unfortunately we cannot use the actions to set the direction of motion. The reason is that this would interfere with the vertical motion used for jumping and falling (and later climbing). Instead we simply change the position. We can either use actions or code for this. Using actions we do the following. In the event for the left arrow key we need one action to test whether a position is empty. Give as relative values -4 and 0. (So we test whether the position left of the current one is empty.) The next action, that is executed only is the position is indeed true, lets the character jump relative to position –4, 0. Do the same for the right key event but now using 4 rather than –4. In code we use the following:

{
if place_free(x-4,y) x -= 4;
}

4 indicates the speed, that you can change if you like.

Jumping

Next we need the vertical motion. This is more difficult. To let the character fall down we can use gravity. But it should stop moving when we hit the floor. Also, you normally want a maximal falling speed, otherwise the character will move too fast. (This is both not very pleasing but it can also cause problems in the implementation.) To this end we put the following piece of code in the step event of the character. It sets the gravity based on whether there is something below the character (by checking whether the position 1 pixel below the character is free). Also it limits the vertical speed.

{
// set the gravity
gravity_direction = 270;
if place_free(x,y+1)
gravity = 0.5
else
gravity = 0;
// limit the speed
if (vspeed > 12) vspeed = 12;
}

Next we have to land. This is more difficult than it might seem. It will happen when the character collides with the block object. In this collision event we should set the vertical motion to 0. But this might leave the character hanging a bit in the air above the ground. (The reason is that the character is placed back to its previous position before the collision.) To this end we want to move the character downwards until it hits a block. We do though need to do this only when two conditions hold: the character is falling down (so vspeed > 0) and there is a block directly below us (so not place_free(x,y+vspeed)). Otherwise there can be (rare) cases where the character suddenly jumps up or down. This is achieved by the following piece of code, which must be placed in the collision event with the block:

{
if (vspeed > 0 && not place_free(x,y+vspeed)) move_contact(270);
vspeed = 0;
}

Finally we have to let the character jump when the up arrow key is pressed. But this must only happen when the character is currently on the floor. This can be achieved by the following code.

{
if (not place_free(x,y+1)) vspeed = -10;
}

You might have to play a bit with the vale of 10 for the vertical speed and the value of 0.5 for the friction to get the motion you want.

Now the basis for the platform game is ready. Design a level with some floors and walls, constructed from block and a character is in, and you can move the character around. Note that most of the code above can also be done using actions. Only the move_contact() function is not available as an action.

Better graphics

The basic platform game we created in the previous section works but looks rather bad. There are two aspects we want to change: the way the player looks, and the way the background looks. The adapted game can be found in the file platform_graphics.gmd (ATTACHED).

The character images

Let's start with the character graphics. We will use two different (non-animated) sprites: one for the character facing to the left and one for the character facing to the right. The easiest now is to place in the event for the left arrow key an action to change the sprite to the one facing left. Similar, in the right arrow key you switch to the one with the character facing right. You probably don't want to use precise collision checking for the two sprites. This avoid that the sprite get stuck halfway down the edge of the platform. Finally, you better make sure that the bounding boxes of the sprites are the same. Otherwise, switching from left to right might cause problems in rare situations. (You can always use manual bounding boxes for this.)

In more advanced games you will probably want to use animated sprites. In this case you also need a sprite for the character when it is not moving. Also you might want to add sprites for the character jumping, falling, shooting, etc. In this case you will have to change the sprite at various places in the events. In particular, in the no key event you probably want to set the sprite to the no moving one. Alternatively, you can draw the correct sprite in the drawing event based on the situation. For example, you can check whether xprevious

The platforms and walls

Secondly we want to improve the background and the platforms. Here we use a standard technique.

Rather than using objects for all the different wall and floor elements, we use so-called tiles. Tiles are pieces of background images that are drawn at particular places in the room. They do not have associated events nor do they create collision. The good part is that they are fast and use little memory. So you can create large rooms without the need for large images.

To add tiles to your rooms you first need a background image that contains the tiles. Tiles in a background image preferably have a fixed size and have a little (1-pixel) border between them such that they can easily be separated. A number of tile sets are provided with Game Maker but you can find many more on the web. For our simple platform game we made our own, small one. We added it as a transparent background resource named background_tiles.

Now, when creating a room, you can click on the Tiles tab page. You can select the tile set (that is, the appropriate background resource) and you might have to indicate the tile width, height, and separator size. Now you can draw tiles by clicking on the appropriate tile and next placing them in the room, like you would do for objects. The right mouse button deletes tiles. Use your imagination to create challenging rooms. (Note that you can also place foreground tiles. These will always lie in front of the moving characters. We will not use them here but they are great for giving a better 3D effect.)

We will draw all the nice platforms and walls on the background image. For this we use the option to create a tiled background. (See chapter 15 of the documentation.) You can use a second background to give the platforms again a nice background. In this case don't forget to make the background with the platforms transparent.

There is a problem left though. As indicated above, tiles are just nice graphics. They do not generate events or collisions. So the character would fall straight through them. To avoid this we still need the block objects we had before. We place the block objects at the appropriate places on top of the walls and platforms you did create with the tiles on the background. Now by making the block objects invisible you will not see the black blocks but the beautiful tiles. But the block objects are actually there, so the character cannot pass through the walls and will land on the platforms. There might be one problem here. The 16x16 block objects might be too large to cover the background nicely. So we want to make a few other block objects of size 16x8 and 8x16. Again we make them solid. To avoid having to specify collision events with these as well, in the Advanced tab of the objects set the parent to the block object. In this way they will be treated the same as the bigger block.

Threats and treats
Just jumping around from platform to platform is rather boring. You definitely need some more challenges and goals. In this section we treat a number of these. Check out the game platform_monsters.gmd (ATTACHED) for the result.

Monsters
Let us first add some monsters. We will make two monsters, one that moves left and right on a platform and the other that flies left and right in the sky. Jumping on top of it can squash the first one; the second one should be avoided at all times.

Let's start with the monster that moves on the platforms. We need two sprites for it, one with the monster facing left and the other with the monster facing right. Now we create the monster object. In the creation event we let it move to the right with a particular speed. Whenever it hits a wall it reverses its horizontal speed. To draw the correct sprite we put the following code in the drawing event:

{
if (hspeed > 0)
draw_sprite(sprite_monsterr,-1,x,y)
else
draw_sprite(sprite_monsterl,-1,x,y);
}

Based on the value of the variable hspeed (that indicates the horizontal speed) we draw the correct sprite.

To avoid monsters from falling off platforms, we introduce another object, which we call a marker. This marker will be an invisible red block. Whenever a monster touches it, it reverses its orientation.

When the character hits a monster the monster or the character should die. To find out what must happen, in the collision event of the character with the monster we perform the following test:

vspeed > 0 && y < other.y+8

If the result is true, the character is moving downwards and hitting the top part of the monster. This means the monster must be destroyed. (In the example we turn the monster into a dead monster, which destroys itself after a while. This gives a nicer graphical effect.) In this simple platform game, dying for the character corresponds to restarting the level, which can be achieved by some simple actions.

The flying monster is even easier. We proceed in exactly the same way. Only, in the collision event of the character with the flying monster, no test needs to be performed.

You might want to add some more monsters, e.g. with different speeds, to make things harder. You can also make a monster or rock that falls down or moves up and down. Just use your own imagination.

Pits

Most platform games require careful timing of jump to avoid falling into pits. Falling into a pit normally kills the character. To this end, we add a new object, called death. This object is a red block that again is not visible. You can place it at the bottom of the pit. (In the background image you can put some spikes there.) In the collision event of the character with the death object it should play a sound, wait a while, and restart the room. You can also make pits that go down infinitely. In this case you want to add similar actions in the outside event (in the other events) of the character, maybe including a test the y > room_height to make sure the character fell down, rather than jumped up outside the playing field.

Collecting points

Most platform games have some mechanism in which the player can collect points. Normally you have to pick up certain objects or catch certain things. In our example the player can collect mushrooms. So we make a mushroom object. To give a bit of variation, the mushroom sprite contains 10 different mushrooms. The mushroom object picks one at random upon creation. To this end we set the variable image_single to random(10). In the collision event of the character with the mushroom object we play a sound, destroy the other object and add 10 to the score.

In some platform games, collecting things has a more important function than just raising your score. For example, you might get an extra life when you collect enough objects. Also there might be objects that restore your health (assuming monsters don't kill you but simply weaken you), make you move faster, jump higher, etc.

Next level

Of course there should be a way to finish a level, such that the player can move on to the next level. To this end, we create a levelexit object. When the character gets there you are moved to the next level. In the example this is done rather simple. We only added a test whether room==room_last. if this test is true we are at the last level so we can no longer move to the next one. Instead the highscore list is shown and the game is restarted.

You might choose to make the levelexit only appear when for example all mushrooms have been collected. To this end, in the creation event of the levelexit object, it is move to a position –100,-100 (so off the screen). Now in the step event of the levelexit we check whether the number of mushroom objects is equal to 0 and, if so, move the levelexit object back to its starting position.

More motions
Our current platform game has just some limited motion possibilities. The character can move left and right, and it can jump. To make things more interesting, let us add some possibilities. The result can be found in the game platform_motions.gmd (ATTACHED) .

Ramps
It is nice if the player can walk up sloping ramps (down goes automatically because of the falling). To this end, we have to replace the code in the left arrow key event. We put there the following:

{
for (i=0; i<= 8; i +=1)
{
if place_free(x-4,y-i) { x -= 4; y -= i; exit; }
}
}

This might be a bit difficult to understand. What the code does is try all choices for i from 0 to 8. For each of those it checks whether position x-4,y-i is empty. If so, it moves the character there and exits the code. So the program first tries whether we can move just to the left. If not it tries to move one pixel up. If that does not work, it tries two pixels up, etc. (We go on till 8 to also allow walking up a sort of stairway.) Similar code must be put in the right arrow key event. That is all.

Ladders

People always want ladders in platform game along which the character can move from one platform to the other. This requires a bit of work. A ladder will be represented by a thin vertical block that is invisible (the real ladder or vine or whatever that is used for climbing is drawn using tiles) and not solid. When the character is not in contact with a ladder motion should be as before. But when it is in contact with the ladder things must go different. First of all, the character should not fall down. So in the step event we have to make a change to this effect and add the following code at the end:

// check for a ladder
if place_meeting(x,y,ladder)
{ gravity = 0; vspeed = 0; }

The second thing that needs to change are the actions for the up key. When the character is at a ladder, the up arrow key should move it up, rather than jump. So the new code becomes:

{
if place_meeting(x,y,ladder)
{
if place_free(x,y-3) y -= 3;
}
else if (not place_free(x,y+1)) vspeed = -10;
}

Also, the down arrow key should slowly move the character down the ladder, using a similar piece of code. Finally, you might want to create a separate sprite for the climbing character and, in the step event, change the sprite when in contact with a ladder.

Using a view
Up to now we always showed the entire room. For many platform games this is not what you want. Instead you want to see only a part of the room, around the character you are controlling. Fortunately this is extremely simple to achieve in Game Maker. When designing the room, click on the Views tab. Click on the checkbox Enable the use of Views to start using views. Select the first view and check the box Visible when room starts to make sure this view can be seen. Give it a width of 300 and a height of 200 (or something else that you like). (As we are going to let the view follow the character there is no need the specify the left and top position of the view in the room. Also, because we use just one view, we don't have to specify the x and y position of the view on the screen.) As the object to follow we choose at the bottom the character. The view will now automatically move to keep the character in focus. We don’t want the character to get too close to the border. To this end we set the Hbor and Vbor values to 64. There will now always be a 64 pixel area visible around the character. Finally, to get a smooth view motion we set the maximal view speed to 4. (This also gives a very nice effect at the start because the character comes slowly into view.) Having the view is nice but it makes the window in which things happen rather small. To avoid this, in the Game Options we set the scaling to 200 percent. Clearly you can play with these values to get the effect you want.

What next?

The sections above should have given you a number of the basics of making platform games. Now it is your turn. You will have to use these techniques and some more ideas of yourself to create a real nice platform game. Remember that the most crucial part of platform games is the levels. Start making levels one by one. Play them until you are happy with them. Every so often, introduce some new game play aspect. Here are some ideas that you can use:

different monsters, e.g. bouncing balls and monsters that shoot
the ability of the player to shoot monsters (maybe only after a gun is found)
keys that you need to find in order to open doors
mines that you can place somewhere and that go off when a monster (or yourself) steps on them
water to swim in (this will completely change the motions; no gravity anymore, or a mild upwards gravity until you reach the surface, limited time before you run out of air, air bubbles to grab, etc.)
walls and floors you can destroy, e.g. by shooting them or jumping on them with force
trampolines that make you jump higher
platforms that appear and disappear
one-way streets
moving platforms (this is not easy!)
…

Good luck.

tiles.gif (Size: 3.16 KB / Downloads: 434)

Platform Examples.zip (Size: 160.49 KB / Downloads: 413)

Guide to Good Programming with Game Maker

Thu, 15 May 2025 03:53:31 +0000

This article was archived in February 2002
when GameMaker 4 was released.
I probably snagged it at GamingWorld
Yet concepts should still hold.

Guide to Good Programming and Game Making Practices with Game Maker

(For Game Maker 4.0 and above)

By Allen Cheung

(Allen_Cheung@hotmail.com)

1 Contents

1 Contents
2 Introduction
a) Credits
b) Program Information
c) My Position
d) Purpose
e) Level of Usage
3 General Concepts
a) Object Orientation
b) Event-driven
c) Inheritance
d) Variables
e) Scripts
f) Loops
4 Style
a) Indentation
b) Comments
c) Naming
5 Scripts
a) Scripts as Procedures
b) Scripts as Functions
c) Portability
d) Examples
6 Variables
a) Data Structures
b) Arrays
c) Arrays of Objects
d) Constants
e) Variable Usage
f) Global Variables
g) Custom Data Structures
7 Object Orientation
a) Organizing Objects
b) Inheritance
c) Events
d) Controllers
8 Efficiency
a) Loading
b) Memory
c) CPU Resources
d) Algorithms
9 Final Words
a) Summary
b) Corrections
c) Another Guide?

2 Introduction

Credits

First, acknowledgements go out to Mark Overmars for creating a one-of-a-kind program that makes making games much, much easier than ever before. Also, much thanks is needed to give to the numerous tutorials, examples, and sample games/programs (too much to name, unfortunately) found online which serve as a welcoming embrace into the world of game making with Game Maker.

Program Information

The program that this document shall focus on is Game Maker 4.0, by Mark Overmars. It is a very powerful utility for programmers and non-programmers alike to create 2D games of old, classic games such as platformers, top-down shooters, puzzlers, RPGs, etc. – all of which existed in 2D form. This amazing program can be found here: http://www.cs.uu.nl/~markov/gmaker/index.html

My Position

Indeed, as pointed out above, it’s a fairly easy task to make games with Game Maker 4.0 (GM), due to its simple drag-and-drop interface. A lot of the coding common to experienced programmers has been simplified into buttons that are used mostly in games – changing variables, adding sprites, etc. – has all been taken care of by the program. However, Mark has done one better by giving the user the ability to enter his or her own programming via the Game Maker Language (GML), which multiplies the usefulness of GM tenfold.

It is in the GML that I see the true power of GM emerging. While the visual interface is useful for non-programmers to jump right into the action, all of those actions can be successfully completed via code. Furthermore, the rich library of functions provided (and often unused, sadly) give the programmer a diverse set of tools to complete his or her task; he or she should certainly not be limited by the drag-and-drop interface.

Yet, as a Computer Science major, I often cringe at the code that is used by GM users. While it is certainly not expected of non-programmers (which this program is designed for) to program with perfection just from GM alone, there still exists much improvement in areas. This is not merely an aesthetic criticism; it is also a practical matter, for cleaner and better programming usually results in less confusion, reduced code, and general happiness for all.

Purpose

The purpose of this document is to give the user a greater understanding of GML, the techniques involved, and the untapped power within. I realize that some of this is covered in the manual of the program itself (http://www.cs.uu.nl/people/markov/gmaker/doc/gmaker.htm), but these concepts are important enough to bear repeating, over and over again, until you get bored and tired of reading them. Then you may promptly close this document and flame me.

Level of Usage

To fully utilize this document, it would be best for you to already be familiar with GML; preferably, you have used some code in your programs, either to shorten the long list of actions and events or to accomplish a few functions not in the scope of those drag-and-drop techniques.

3 General Concepts

We begin by presenting a few general concepts that will vastly make the non-programmer more knowledgeable to the ways of programming.

Object Orientation

What is Object Orientation? What is Object-Oriented Programming (OOP)? GM is founded upon this system of programming, but what is it really?

OOP is a style of programming popularized with C++ and such languages of the past; it has become widespread with the emergence of a wave of visual development languages, such as Visual Basic, Visual C++, and Delphi. Basically, the concept behind OOP is that independent objects make up the program. Each object knows how to take care of itself, and nothing more; it holds all the procedures, routines, and functions needed to run its own purposes. This is seen in GM by the various sections of an object – it takes care of its own creation, destruction, movement, counter, alarm, and input.

Event-Driven

Yet another buzzword. This simply describes how OOP is run, which is by events – the program acts only when an event is detected, and is idle otherwise. For example, GM has events for keyboard commands; the system sits idle until a key is pressed, then looks to see whether that key triggers some snippet of code. Of course, the programmer can choose to have a continuous event so that the game is always moving – this is embedded in GM’s Step events.

Inheritance

A second feature of OOP is the power of inheritance. Because of the nature of object orientation, it is easy to build a hierarchy of objects, a tree of parent-children couplets. The purpose of such hierarchies is inheritance – that is, the ability for a child object to inherit the properties of its parent. For example, suppose that I have an electronics object, which has the property that it is run by electricity. Now, a child of this object could be a computer object, which not only has the property inherited from its parent (that it uses electricity), but also has the property of having a monitor and keyboard. We can go even further and build a Mac object, with all the properties of a computer object (and thus all the properties of an electronics object) with the addition of having the ability to produce outstanding graphics.

In any case, inheritance is a powerful concept that will potentially save a lot of programming time and possibility programming errors from duplication of code. More on this later.

Variables

Variables are the meat of any useful program; they are placeholders for pretty much everything that can change in a program. There are a number of variable types that GML uses:

Real: Real numbers, that is numbers with decimal places, such as 1.2345
String: A string of characters, such as “this is a string”
Boolean: Either 0 or 1, meaning false and true respectively

And truly, for making 2D games with such computing power, it is not necessary to include any more variable types (unlike the programming of yesteryear, where everything had to be conserved…byte types anyone?).

Scripts

Scripts are the equivalent of functions or procedures in other programming languages; they serve to separate chunks of code so that they can be reused or that the general program is simplified. Sadly, while the latter is sometimes utilized, I almost never see the former used. The power of functions cannot be ignored, for they provide the means to repeatedly do a task with different parameters – taking a number and squaring it, for example. As a matter of fact, they are powerful enough to invoke their own style of programming, known as functional programming and seen in languages such as LISP.

Loops

I think that this topic is general enough to warrant some discussion here. As an old CS teacher told me, computers are only good at doing boring things repeatedly, and I tend to agree with him. The existence of loops (and its manifestations in GM, as while, for and repeat statements) greatly simplifies a lot of code with some simple math, and they almost always work with variables to accomplish their tasks. Smart programmers will take time to learn these well – they make case-checking and otherwise tedious code much more bearable (I’m thinking of a specific code sequence found in a “Code Book” that will remain unnamed here).

4 Style

Well, enough about abstract concepts. Let’s get down to the nitty-gritty stuff. The first topic, before any other, is the discussion of the style of programming. This is the most important factor to good programming practice.

Indentation

Indentation is the process of making code more readable by indenting chucks of code by spaces. By doing so, the programmer can easily check for incorrect bracket placements, bad function calls, and overall program intent. Compare two sample programs:

for (x = 1; x <= 10; x += 1) {
y = 5;
for (z = 5; z >= 1; z -= 1) {
if (z == 3) {
y += 1; s = “Big Bertha”;
}
else
{
name = ‘Bill’;
}
y -= 1;
}
}

and

for (x = 1; x <= 10; x += 1) {
y = 5;
for (z = 5; z >= 1; z -= 1) {
if (z == 3) {
y += 1;
s = “Big Bertha”;
} else {
name = ‘Bill’;
}
y -= 1;
}
}

The first one is left plain, while the second is properly indented; by simple inspection alone, we can conclude that the second one is much easier to read at least – we can easily tell which block (that is, the chucks of code that are bounded by { } ) corresponds to which statement. I can even attest to the fact that it took me a while to actually check that all the brackets were in the right place.

I can’t stress this point enough! I’ve seen enough GML code with no indentation whatsoever, and it is simply a mess to read. Even with small snippets of code, this can easily create programs that are confusing. (try, for example, organizing a triple for loop with nested if statements) It does not take that much effort to properly indent in the first place, and the program and programmer will be much better off for it.

Comments

Comments were included in GML for a reason, and not just because they looked particularly nice either (although I hope that Mark will someday implement the often-used /* */ notation). Once again, they are utilized to make code readable, but for whom that really benefits is the reader. There will be times when you will stumble across code that you have written ages ago, or code written by others, and you will have no idea what it does. So, rather than frustrating your future self and readers, why not just comment obscure code? This is especially important in Scripts, where the name of the Script is usually not enough to tell what is happening, and it’s rather hard to find where the game calls that Script. Just a // may save a lot of searching in the long run.

Naming

While not strictly a GML quirk, it’s still a major topic that concerns a style of programming, and I will quickly note my point here. Simply put, make your names mean something. Calling sprites spr is a good mnemonic to allow yourself to remember that it is indeed a sprite (especially within programs, where you’re not given an easy menu that sorts out everything else), as is calling backgrounds back, objects obj, etc. If you are using four sprites in four directions, try calling them sprHeroLeft, sprHeroRight, sprHeroUp, and sprHeroDown…it certainly sounds more intuitive than s1, s2, s3, and s4.

5 Scripts

Scripts, the way that they are represented in GM, are roughly analogous to procedures and functions. Pointless trivia: in the programming language Pascal, there are both functions and procedures; in most other languages, however (C, C++, Java, etc.), there are only functions. The difference? Simply that a procedure does not return a value, whereas a function does. C and its family of languages get procedures from defining functions with no return type (void). Since GM emphasizes Pascal and Delphi, we will make the distinction as procedures and functions. The importance of scripts, of course, is already highlighted in the section on general topics.

One notational point: since scripts are closely related to functions in other languages, I will abide by the standard convention that scripts have a pair of brackets at the end, regardless of how many arguments are actually in the script. Hence, useObjects is a variable while useObjects() is a script with some undetermined number of arguments.

Scripts as Procedures

Scripts as procedures are simply scripts with no return value, so that they are ideal to perform visual operations such as displaying text and drawing graphics, as well as manipulating objects. One calls scripts analogous to procedures in code as follows:

Some_script (arg0, arg1, … , arg9);

And declaring that script:

{
for (x = argument0; x = argument1; x += argument2) { … }
}

Note that scripts can have up to ten arguments when called within GML code, and that the script itself strives to only use its arguments and not anything else. Furthermore, there is no return statement at the end; the script finishes its operations and goes back to the main program.

The use of script-procedures can be further simplified into two categories: one-time procedures and multiple-use procedures. One-time procedures are created to make coding easier to understand; set_global_variables() and display_graphics() is certainly reasonable. On the other hand, multiple-use procedures are usually more general; examples include moveObjectRight().

Scripts as Functions

Scripts as functions have an important difference, in that they require a return value. Because of this, most uses of functional scripts are to calculate and return some value – for example, some mathematical function. One usually seeks not to change the arguments themselves in a function, only to use them for calculations (although the key here is usually, for there are uses of functions that manipulate their arguments and still return a useful value). They are used in very much the same way:

Ans = some_other_script (arg0, arg1, … , arg9);

And in the script itself:

{
x = argument0 * argument1;
…
return x;
}

The important part is that there is a return value, although one is not obligated to use that value. For example, the provided library function instance_create() returns the id number of the instance, but the user certainly does not have to use that number if, say, the user is merely creating some graphical menu.

As with procedural scripts, function scripts can be largely separated into two categories. The first is already mentioned, and is mostly for calculating without actually manipulating the arguments given. Hence, good examples would be cube() and findSmallestNumber(). The other kind of functional script is less used, but still very useful…scripts like the above-mentioned instance_create() still manages to return useful information.

Portability

Once a script is written, if it is indeed written well, it can be applied to any program or game. Collections of such functions in other programming languages are known as libraries, and GM has its own library of useful scripts. Unfortunately, a lot of scripts that are being written are not truly adapted for other programs right off the bat, for they are hard-coded to a specific program and require some editing on the user’s part to make work. This, however, defeats the purpose of scripts – ideally, one only needs to read the description of a script to figure out its usage.

To achieve this, the script-writer is advised to write his scripts using the arguments given, rather than hard-code variables that are used in the original program that the script is written for. For example, a line of code such as { y = ball.x; return y; } will throw errors an any program that does not contain a ball instance; one must edit this script to fit with whatever the script is used for. However, if the script required one argument, such that { y = argument0.x; return y; } , then as long as the user passes an argument, the script will work. This is known as “adding a level of redirection” by using a variable in place of actual objects.

Examples

Since scripts are so important, I want to present a few examples as to good script programming. Perhaps the best way to practice this is by writing scripts by themselves as I am doing here; you will be forced to remove yourself from the context of a program and thus generalize your scripts. Feel free to copy and paste them into your code, using them as per the comments.

// Returns the square of arg
{
return argument0 * argument0;
}

// Concatenates two strings, returns it
{
return argument0 + argument1;
}

// Moves object arg1 spaces on a diagonal
// Arg0 is the object, Arg1 specifies distance
// Arg2 is direction – 1 = NW, 2 = NE, 3 = SW, 4 = SE
{
localx = argument0.x; locally = argument0.y;
if (argument2 == 1 || argument2 == 3)
localx -= argument1;
else localx += argument1;
if (argument2 == 1 || argument2 == 2)
localy += argument1;
else localy -= argument1;
argument0.x = localx; argument0.y = localy;
}

// Find the angle between two objects, in degrees
{
disX = argument0.x – argument1.x;
disY = argument0.y – argument1.y;
tanRadians = tan(disY / disX);
return tanRadians * 180 / (2 * pi);
}

I may create more scripts later if demand is great, but hopefully these few examples will serve to show the clarity that a good script can provide.

6 Variables

It is fair to say that a lot of programming and video games revolves around variables and their usage. They are what make programs interactive – the user can input data, have his input stored as variables, and the program outputs meaningful data. As such, it is worthwhile to explore and explain the value and good use of variables.

Data Structures

What are data structures? They are merely types of variables; for example, while S may be a variable, the type string can be considered a data structure. As explained in Section 2, General Concepts, GM provides three easy basic data structures: strings, real numbers (reals), and booleans.

Arrays

One important data structure that GM provides is an array, up to two dimensions. An array is a collection of similar data structures that can be easily accessed; it is an orderly progression of data. They are declared as follows:

Arrayname[number]

So that arrayname is name of the array, and number is the counting number (starting from zero) that contains a variable, also known as an index. In a way, an array can be thought of as a row of variables:

[0] [1] [2] [3] …
15 178 3 84

In the example above, arr[0] would return 15, and arr[3] would give back 84.

The reason arrays are useful is that they can be accessed via simple counting, which is perfect for loops. By going from 0-9, for instance, one can quickly go through 10 similar variables and assign values to them. Consider the code:

{
s = ‘’; // ‘’ is the null string, kind of like the number 0
for (n = 0; n <= 9; n += 1) {
s += chr(n + ord(“A”));
arr[n] = s;
}
for (m = 0; m <= 9; m += 1)
draw_text(10, m*10+10, arr[m]);
}

Looks intimidating, but it really isn’t so bad. All the code does is first set the string variable s to the null string, then enter a loop that repeats ten times. Each time, s adds another letter to the end (remember that s += n is really shorthand for s = s + n), with that letter being the next letter in the alphabet. (a quick explanation: ord() gives the numerical ASCII code of a character, so adding to that code will produce further letters down the line, and chr() will convert that number back to a character) It then stores that string into an array arr, which will have 10 elements (0-9) by the end of this loop. The last loop will then print the contents of that arr, which should be:

A
AB
ABC
…
ABCDEFGHIJ

With correct spacing from draw_text(), of course. The point here was that because of the nature of arrays, you can easily run through the entire thing without inventing ten variables to store ten variables that differ only by their value.

GML also allows the use of two-dimensional arrays, formatting as follows:

TwoDimensionalArray[num1, num2]

Where num1 and num2 are the two indices of the array. Just as a 1D array can be thought of as a row of data types, a 2D array is merely a table (rows and columns) of data. Since GM is in the business of creating 2D games, such arrays may come handy in, for example, representing the contents of a nxn grid (in a sliding puzzle game). Unfortunately, this is as high-dimensional as GM goes, but should be enough for all purposes.

Arrays of Objects

An excellent use of arrays would have to be in storing similar objects and instances. GML itself already provides one such grouping for you – instance_id[n] is an array of all the instances of an object. You may also manually store instances as a part of an array as well – for example, in an RPG with a large party, one can use something like:

…
wholeParty[0] = objHero;
wholeParty[1] = objEvilHero;
wholeParty[2] = objNinja;
…

Then, when the time comes to do something to the entire party (like taking damage from a mass-destruction spell), we need not stress ourselves over the code:

for (n = 0; n < numPartyMembers; n += 1)
with (wholeParty[n]) {
damage = random(defense) + enemyMagic;
HP -= damage;
}

And voila, our entire party has just taken damage from the spell, where each individual has calculated his/her own damage levels according to their own stats. Mark also notes that with instances of the same object, they are already stored in an array (the instance_id[n] above is that array), and that to cycle through all the instances, the command with is provided. More on this command can, of course, be found in the official manual.

Constants

We now move onto the discussion of constants in a program. Constants are global variables that are declared in the beginning of a program; they are there usually as general bounds to certain parameters. Taking our RPG example above, we can set the maximum damage to no more than 9999, and max health the same number in the beginning of game:

global.MAXDAM = 9999;
global.MAXHEALTH = 9999;

Then in your actual code:

if (HP > global.MAXHEALTH)
HP = global.MAXHEALTH;
if (damage > global.MAXDAM)
damage = global.MAXDAM;

Programming naming convention usually gives constants all capitals. The point here is that by declaring these variables in the beginning, you can easily look up what the numerical values are. Furthermore, if your code uses a certain constant multiple times, when time comes to change the number (from play-testing, perhaps, when you find that 9999 isn’t enough health), all that is required is a quick change in the beginning of the code, and everything else will fall in line.

Variable Usage

As you begin to make more advanced games or simply just more games in general, you will begin to realize that not a lot of numbers need to be explicitly given (this is not true for strings, however) – explicitly using a “magical number” is known as “hard-coding”. You will also begin to notice that your program will behave just as well with one value as well as another, given that your data structures and overall organization is reasonably solid.

You can take advantage of this by providing the gamer with options. From experience, most games created in GM tend to be started linear – one loads the game, reads the introduction/instruction screen, then one begins the game itself. Unlike most professional games, an options screen is not provided, when having one does characterize quality in that game. They do not even need to be tedious; a platform game, for example, can have the player choose between easy, medium, or hard, and assign lives 5, 4, and 3 respectively to the gamer. Or he can up the speed of his monsters with increasing difficulty. Perhaps the main character will walk slower/faster, and jump lower/higher. The numerical nature of games and programming almost begs for manipulation, so why not add a professional polish to your game?

Global Variables

GM allows for global variables in the form of:

global.var = x;

Where the keyword global signifies that the variable can be used, called, and changed anywhere in the program. While this certainly sounds great, the old adage “too much of a good thing will ultimately reduce you to the shadow of a man you once was and make you beg for mercy” (paraphrased) is certainly applicable. In programming, overuse of global variables is shunned, and GML is no different in this regard.

While GML avoids the issue of namespace (it’s just a fancy term for the available names that you may give your variables…makes a difference in complicated and large programs) by requiring the use of global, the practice is still bad because of the potential to make your program less object-oriented (this is explained in further detail in the next chapter). By all needs, you should not even need global variables – controller objects (also explained in the next chapter) should be enough to keep track of all variables that are needed in your game. In other words, they are provided as a convenience, and there is often the temptation to use them boldly to avoid otherwise clean code (for example, to avoid passing arguments to scripts by setting a few global variables and changing those). They are not completely horrible, per se, but extensive usage simply shows that you have organized your program poorly.

Custom Data Structures

As mentioned above, it does not appear to be the case that one can make one’s own data structures in the context of GML. However, there are ways around this, though they may not be so obvious to the casual GM user. The general idea is to create a custom object that houses all the data that you need.

You may be at a loss to figure out why anyone would need such a structure, so let’s give a quick example. Suppose that you want to write a script that returns two distinct strings. Normally, this is impossible, as a script can only have one return value. Hence, you would need some sort of container or data structure to house both strings. The answer? Create a dummy object that has two local variables of strings, then in the script, stuff those two strings in there and return that.

For the most part, however, you probably will not need these custom data structures. As Mark has so carefully informed me, GM is not based on dynamic scope, but rather seems to be more lexically scoped (for those that don’t have any idea what I’m talking about, ignore it), so variables tend to stick around, it seems. In any case, this little trick is here for those that would use it.

7 Object Orientation

Being object-oriented means much more than just having objects; as discussed in General Concepts, it also provides a number of useful properties that we can use to the fullest. I present them here.

Organizing Objects

The name “objects” really should notify you of the fact that they are intended to simulate (remember that all computer programs are simulations) a single object in reality. As such, organize objects wisely and logically; not only can sloppy handling of objects be potentially confusing, but it will probably eat up resources as well, which will ultimately slow down your game and make it much less appealing to play.

One such example concerns, say, having four sprites for four directions of a character. The logical thing to do here is to create a single object and have it switch between the four sprites, rather than have four separate objects each with a separate sprite, so that objects are destroyed and created when the player moves around. Similarly, when one creates a fighting game, one creates one instance of an object, and allows that instance to change its sprite frequently (it would probably be a good idea to make sure that the object had precise collision detection too). In any case, getting exotic with objects and instances is not recommended, although by now I probably should not have to tell you that explicitly.

Inheritance

One of the big topics discussed was inheritance, and that is indeed a great timesaver in a lot of situations. All inheritance means is that a hierarchy of objects exists, in the form of parent-child pairs. A child “inherits” or automatically possesses all the properties of the parent, plus whatever the child wants to add and overwrite. A quick example: a spell object would have a child object fireball, which qualifies as a spell but has the additional property that it does damage. A cure would also be a child object of spell, but instead would have the property to heal.

The power of inheritance comes into play when we define parents that have attributes that all children share; we then only have to define that property once in the parent, and it will automatically be reflected in all the children. A more involved example:

Spell
/ \
/ \
/ \
SingleTargetSpell MultTargetSpell
| / \
| / \
| / \
Fireball Firestorm Cureall

In the hierarchy above, we notice that there are actually just three spells – Fireball, Firestorm, and Cureall. However, they are grouped very systematically via parents as well, all the way up until they all fit under the grouping of Spell. Why is this useful? Let’s have some sample code:

// In objSpell
{
MP -= MPused;
}

// In objSingleTargetSpell
{
enemy[targeted].HP -= damage;
}

// In objMultTargetSpell
{
for (n = 0; n < numEnemies; n += 1)
enemy[n].HP -= damage;
}

// In objFireball
{
damage = 50;
MP = 15;
}

// In objFirestorm
{
damage = 100;
MP = 50;
}

…

We can see that with each layer, we simply add to the properties. We know that all spells consume MP, therefore that property is placed under Spell. Then we notice that the damage taken differs between SingleTargetSpell and MultTargetSpell, so we make different code bodies for those as well. Finally, we give those variables actual values with Fireball, etc. (note that I have not specified where one would place this code; you would have to fool around and figure that out; remember that there is an action for calling a parent’s action/event) When all is said and done, a completed hierarchy of parents makes it very easy to create new spells; just designate the damage, the MP usage, and place it in the right place.

If that was too complicated and too specialized, then I’ll give an easier example as well. Suppose that you want your character to take damage whenever he touches a monster. Now, that sentence alone should clue you in on what kind of a hierarchy you should build – just a parent monster, with children being the actual monsters. All that you need to be defined is when the character collides with the parent monster; every single child will inherit this property, and will behave properly thus.

Events

Another property of OOP is that all action is driven by events. Unlike other types of programming such as procedural (where you will plow through the main program), OOP operates on the premise that action happens only when an event occurs to trigger some action; otherwise, the system sits idle.

A mistake that some GML users make here is that they want to make the language procedural – perhaps they are used to the ways of C, Pascal, and BASIC. The closest thing to procedural programming in GM would be the Step event, which occurs in short regular intervals as the program is running. This event was designed for continuous operations – taking input from the player, for example – but for actions that occur less often!

I regularly see code that will attempt to draw a sprite in its step event, repeatedly for each step, when it is definitely not necessary to redraw the same graphic over and over again. Instead, why not draw when you know the graphic will be different? For instance, say that a lifebar needs to be drawn and updated. A smart (meaning one that has read this document thus far, of course) programmer would only redraw the graphic when the life total changes; if he has learned his lesson from this guide, he would bundle that code to change the life variable and redraw the lifebar into a script and call that. A not-so-smart programmer might try to draw the lifebar in the Step event, resulting in a lot of wasted CPU power as the same image gets drawn over and over again.

Of course, while my emphasis here is on graphics (which is almost always the most CPU-taxing portion of a game), it certainly applies anywhere else. This is not to say that using the Step event is bad by any means; rather, it cautions abuse and overuse of the event, which will bog down your game more than you would really want. Just be conservative about its usage, and you will be fine.

Controllers

In an entirely object- and event-driven world, a backstage is still needed for everything to play in; in GM, that would be the special object known as the controller. The controller should be familiar to most GM users; for those that are not familiar to this concept, it is merely an object that oversees everything in its domain, be that a group of enemies, a Room, or the entire game. Within the controller is stored all the vital variables that do not belong anywhere else – the formation of ships, for instance.

In contrast to the last chapter’s topic about global variables, controllers are indeed a good programming practice. It keeps your games object-oriented (as intended by GM), and it gives you very precise control over each area that you want to address (different controllers for different rooms). Fortunately, this is one of the ideas that is well-used in the GM community, so there is not much to reprimand.

8 Efficiency

As games and programs become increasingly larger, they will inevitably become more complex, which means that more CPU power, more memory, and more time is required to run them. With small games, inefficient use of code is excusable, but in cases where every drop of power is savored, perhaps it is a good idea to be conservative in your resources, especially for older computers. Here are a few issues that may arise.

Loading

When GM loads a game and every subsequent room, it must first load all the graphics, sounds, backgrounds, and objects into the room first, along with their accompanying code, actions, and events (unless, of course, you specified that they to be loaded at runtime). The trick here is to try to minimize all the stuff that is being loaded in, and this is done by carefully choosing which things are needed when. For the most part, this process is obvious; if you have an option to choose a song, load that song at runtime. If you have rare special effects in the form of animations, unless they are truly grand and gigantic in size (which risks slowing down the actual game), have them load on runtime too.

Another idea is to limit yourself on the size of the files themselves. If permissible, use MIDIs, not .mp3s. Try to use .jpgs as much as possible, unless GM forces you to use .bmps. Keep rooms small in size, preferably under 1000x1000; split a room up if you have to (as large rooms usually occur in adventure games). An interesting idea is to make use of the custom drawing functions provided in GML – true, they tax CPU resources (as with most things in computer programming, advantages and disadvantages are often traded off), but they may be a good alternative to having a large collection of sprites if those sprites are mostly geometric (hence easily reproduced by simple drawing functions).

Memory

This topic should be a no-brainer to most GM users, as it parallels much of the tips given above. Simply put, the less loading, the less memory required (in terms of RAM requires, page file sizes, and overall program size, as they will be mostly obtained from downloads on the web); keeping things compact is the way to go in this situation as well.

CPU Resources

This one should be a biggie. Having a slow game, no matter how pretty with how many sound effects and exceptional controls, is a drag. Unfortunately, even with the relatively simple 2D premise of GM, it is not easy to create a large game and still have it run at decent speeds, at least not on a run-of-the-mill computer (at the time of this writing, such a computer in the GM community seems to be a PII 350 or so, perhaps lower).

The idea here is to make one’s code as streamlined and efficient as possible. I have already discussed a little of this above, under Events of Section 7, and I urge again not to go crazy on the Step event and creating a lot of unnecessary graphical updates. Other ideas echo the suggestions above about keeping memory and loading requirements to a minimum. For instance, I have played a shooter that I believe tried to simulate snow by having hundreds of snow objects fall in the foreground – this is obviously not a good idea! In another case, I played another shooter where it ran exceptionally slow, which I suspect is due to the huge amounts of animation that it required to be displayed on screen at once. In such a situation, it is advisable to just simply cut some of the animation; since the game is going to be choppy anyway, cutting out a few frames of animation will usually make the game go faster while keeping the same animation. Remember, just because your Athlon XP 1900+ is able to run the game well doesn’t mean that your target players with PIII 450’s (for the record, this is what I’m using to run the games) are going to do as well.

Algorithms

Don’t let that scary-looking word strike fear into your vocabulary – it’s just a technical term for a series of steps needed to accomplish some task. Whenever you write a script, chances are that you are writing an algorithm; in life, we use algorithms to conduct daily activities all the time.

The reason I bring this up is that as code gets more complex, it becomes less and less obvious what is going on. This is especially true for a programming idiom known as recursion (although the average GM user will not need to use this at all), but it just might pop up in less intuitive cases as well. The point here is to write efficient and fast code, but don’t go overboard. As an old programming professor once told me, it’s probably better to trade off extreme efficiency for some legibility and understanding. For instance, say that you have a list of items in a character’s inventory, and you want to give the player a nice, sorted list. Now, there are a lot of ways to do this (or, in computer lingo, lots of algorithms), but some ways work better than others in certain situations, so knowing what the sorting algorithm does and why it works is usually preferred before using it. Obviously, the average GM user doesn’t care about this, and really, such in-depth studies are irrelevant unless you have a list thousands of items long anyway, so why not just go with an easy one that you can understand?

Final Words

Summary

Well, you’re certainly read a lot, and I’ve certainly written a lot. In any case, if you have gotten this far and you have learned a few things from this document, I would say that you’re going to make your GML code a whole lot better. From style, to the ideas of orient-oriented programming all the way to having efficient programs, we have touched lightly upon some ideas that make for good programming, which ultimately makes for better games. If nothing else, these concepts are not restricted to GML alone; my numerous references to other, more prominent programming languages should hint to you that they are applicable in real life also…well, as real as the cyber world, anyway.

Corrections

As I’m well aware, I’m hardly perfect, and I have indeed made a few blatant assumptions here and there through the guide. As such, if anybody has corrections to anything here, please do not hesitate to e-mail me and tell me what it is, whether it is a typo, a grammatical error, a coding problem, a misconception, or a request for clarification.

Another Guide?

After having finished this one and thoroughly enjoying writing it (although, sad to say, it’s only now during break that I have the time and energy to expend for such endeavors), I’m thinking of writing another guide on tips for making a game more professional, along the lines of making lifebars, allowing the user to customize his keys, etc. Let me stress, however, that if I ever decide to write such a guide (which will be determined on whether this guide will be read and be useful or otherwise), it will be a conceptual guide and not a code guide. Simply put, my philosophy is to understand, not to blindly follow, so those looking for a place to rip code will sadly be out of luck. There are other places for that.

“If you like it, let the author know. If you hate it, let the author know why.”
- Open Source Programming Adverb (but applicable anywhere)

Allen Cheung
Berkeley, California, USA
Allen_Cheung@hotmail.com

RPG Developer Bakin: Video Tutorial - How to make a Visual Novel

Thu, 19 Dec 2024 12:41:19 +0000

Hello Save-Pointer-ites! I wanted to just bring this over for a hotlink of the 2024 Tutorial Jam we held back in the summer. This particular tutorial, one of my faves, goes through the basics of creating a visual novel, created by IDOLLDev.

I'd also encourage you to check out her other videos, and if you like it, smash that subscribe button.

Beta Testers

Wed, 25 Oct 2023 00:10:06 +0000

An old Article I had for a couple years and
decided to post... I didn't write it.

Beta Testers
by Angroth
Jan 14, 2004

It wasn't until recently that I bothered to think about just how many people offer for beta testing. Whenever someone needs some help with their game and posts in the forums about jobs people can do if they would like to help everyone always says:

"i'll be a beta tester im good at testin stuff!"

Now I was wondering whether this was due to one of two reasons. Firstly being that the person is genuinely a good game tester and think they could eliminate all errors. Or secondly being that they are too lazy to do anything else and would like to get their name in some credits with the minimal effort (I like the sound of that one personally!).

Either way, testing your game is very vital otherwise (if trying to get the game on GW) AG will send your game back saying there is some big glitch or it crashes at some point. Hopefully I can give you some tips for self testing and who knows, maybe you won't need any beta testers at all.

What Problems Should I Look For When Testing?

Glitches, bugs, errors - whatever you call them, they come in all forms and shapes. I'll list the main ones that are going to drag your game down, these are the ones you should keep a real eye out for.

1 - Graphical Boo Boos! - Undoubtedly the most noticeable of all errors. These will include things such as character sets whereby you see feet coming into the head of one character or when you don't import the graphics and you get big background colours behind them. Graphical errors are pretty easier to spot out and only really make the game a little irritating to play, they shouldn't destroy the gameplay which is good news! You might need a second person to check these out because in the thick of making your game and you can easily overlook slight graphical mistakes.

Graphical problems also involve badly blending graphics and awfully drawn ones (mainly appear within custom battle / menu systems).

2 - Dialogue No Nos! - The thing that bugs me the most is when someone spells things not dreadfully but just moderately so there is enough to annoy but not really hinder reading it. Dictionaries, thesauruses or anything which has spelling stuff in it is your best bet for checking this one out. The main difficulty with correcting this one is if you think a word is spelt in a certain way and it isn't, someone else is going to need to be there to tell you. So once again it looks like someone is going to have to proof read what you're writing unless you are sure about most of your spellings. Sometimes literacy problems can completely destroy your game because it makes it seem like it was made by and for little children.

3 - We're Losing Structural Integrity Captain! - Of all the things that can go wrong this is likely the worst one to do so. Structural glitches are anything to do with the coding and game mechanics itself. Bugs in this section are really easy to fix and correct. Firstly check what the hell you are typing into the events and editor pages (monster's profiles). And after every little piece (a couple of events or maps) or one big event just test your game. I find if I keep testing my game all the way through as I make it I end up with barely any errors. And then after completion play it through and you can knock off any final errors you have made. All problems of this sort can be hard to fix but should be very easy to find and you don't really need anyone else's help here.

4 - Consistancy & Contradictions. - Basically if you have been talking about a character's past and then much later in the game when you meet that special guy it appears you have forgotten about them because they talk of their history and it makes little correlation; or if your quest randomly changes half-way through the game without anyone saying anything, that is a consistancy and contradiction problem. This merely comes from people forgetting (not writing and planning) exactly what's going on and then they accidently refer to things or use them wrongly. And once again this one just needs a good entire play through to notice, and maybe someone else doing it (you know the story and might blur out the mistakes you see). Glitches of this kind can create confusion to the player and make them lose interest and dissuade them from playing.

5 - Little Random Problems. - All the little extras such as a flame spell that looks nice but makes some strange cow sound or if there is no sound because the game is trying to play a midi you have deleted. Little random problems require a beta tester or some thorough looking through your code. Anything that isn't in the top 4 is likely to fall into this section.

What Factors Should I Check When Testing?

Not stricly bugs but things that can still mess up in your game are the storyline, character (development) and so on. Here is what you should check throughout the game.

1 - Storyline - Well as I already mentioned above, story is another factor you should check. What you need to ask yourself is whether or not you liked it, and if you didn't would it accommodate any other people? Was it too complex or too simple? Just what as the things that made you like it, or not?

2 - Characters - Did you like and hate the characters you think you were expected to like and hate? If you hate a character who you really think you weren't meant to, then thats definately not a good sign! Did you feel you knew the characters and understood their actions and comments? Good development in characters should make you not want to finish the game because you don't want to leave the characters behind. And finally in the characters department you need to wonder whether or not the characters had distinct personalities, were they too developed and therefore predictable or not developed enough so you really didn't know what the hell they were doing there?

3 - Music & Sounds - This can be the make or break for most games and films (such as the original Psycho). Firstly did it fit with the game and aid in providing intended emotions? Was it overdone or not enough music? Were the sounds sensible and pleasant to hear? Did the music and sounds provide a good equilibrium with the rest of the game?

4 - Self Determination - Did you feel in control or did you get the feeling you were following somones story and life? Both can be good if done in the right ways. Were there major decisions you had to make that effected the storyline? Did you get chances to wander and explore areas or did you feel pushed for time? Were the explorable areas nice to explore or horrid and a waste of time?

For The Beta Testers

Now, how will you go about telling your game author?

I could talk for a long time about constructive criticism but I think its safe to say we all know not to tell someone, "This r0x0r" or maybe even "This s0x0r!!". So I'll leave that one for now.

Getting Your Game Recognision

Method One: Hands On, Let's Get Busy!

My advice is to firstly find as many forums as possible. Sections such as "Game and Demo" (in our GW forums) will be the ones you should be heading over to. Post a message about your game (use persuasive advertisement language and you're in!!), include the best screenshots possible from your game and if possible show some beta test reviews of it (if you get big names this could help, kinda like in music or film industry). You could also talk a bit about it on mIRC or a similar thing, the more advertising the better. Well, you get the general idea of hands on approach.

Method Two: Sneak In, Sit Back And Watch! (should follow method one)

You're going to need to use all of your sneaky bastard tactics for this one. An example would be subliminally putting it in the minds of the GWians, such as on your posts (if its an article about game development) put something like "Oh thanks a lot, I'll be sure to use this on my game >insert a project here. Or maybe you could befriend a staffer who you can use to advertise your game, infact why not put people in your credits for advertising your game. Anything that allows you to sit back without typing too much is a method two approach.

Well thanks for your patience, but this article has taken a while to write so I'll be on my way now.

Ruby - Behind the Scenes

Sat, 15 Jul 2023 16:52:58 +0000

RUBY
BEHIND THE SCENES

A thread for little-known or overlooked properties of Ruby

This topic is meant to bring up lesser-known or considered concepts when programming with Ruby. Each post within will be an individual topic or concept. And this main post an index of sorts. Currently the initial post also includes a discussion on the constructor, a feature common to both C++ and Ruby.

Other concept will be forthcoming, but not on a scheduled basis

CONSTRUCTORS
(and a little bit on Destructors)

Something both C++ and RUBY Share

Tucked away within the structure of the Class object for Ruby are constructors. Like C++, a constructor is a predefined method built into the Class object, and its primary purpose is to initialize essential variables and content required before use.

And like C++, you will find the use of constructors within any any class within Ruby, Ruby's constructor the aptly named 'initialize' method. Indeed, you do not need to create an initialize method when you create a class as one exists by default. In fact, you do not need to call the initialize method for any class as it is created upon the class object's creation

Ergo, a statement of $scene_mummy = Scene_Imhotep.new which creates the $scene_mummy object actively triggers its initialize method at start, whether the coder included one within the code or not.

Of course, you need not take my word for it. Other experts have made mention:

From EDUCBA (Corporate Bridge Consultancy Pvt Ltd)
https://www.educba.com/ruby-constructor/

EDUCBA on Ruby Constructors Wrote:A constructor in Ruby is part of a class attribute, and it is a predefined method that depends on us we want to use a constructor or not; the primary purpose of a constructor is to initialize the essential variables and required things before making any method calls of the class, the good thing about the constructor is we do not need to call constructor function for initialization of the class it will be initialized on the object creation from the class, to use the constructor method in any class of Ruby we can use initialize method. It will get called on object creation from the class.

Here, EDUCBA clearly states the that a Constructor is a predefined method meant to to initialize the essential variables when a Class object is created. And that the Initialize method is invoked upon the Class's creation

And this is repeated within sites such as:
Designcise A class constructor in Ruby is defined by adding an "initialize" method to the class like so
Geeks for Geeks: A constructor is defined using the initialize and def keywords.

I would be remiss if I didn't provide a rebuttal argument:
Ruby Doc: Programming Ruby: In Ruby, these objects are created by calling a constructor, a special method associated with a class. The standard constructor is called new.

But that seems to be more the exception, and not the rule. And when searching ruby-doc, there is little else other than claiming you need a 'C-Constructor" being .new to invoke the initialize method. Ruby-Doc suggests that '.new' is a constructor, rather than a keyword (or 'method' according to our RPG help files) that triggers the creation of a class... which in turn invokes the constructor. But later within an index covering built-in classes and modules, it does refer to .new as a method that "Creates a new anonymous module. "

● ● ●

The creation of a constructor within Ruby is different then when coding with C++. This because the constructor within C++ is actually written when declaring the name of the class. Yet it is still automatically invoked when the class is created.:

https://www.geeksforgeeks.org/constructors-c/#

Geeks for Geeks Wrote:Constructor in C++ is a special method that is invoked automatically at the time of object creation. It is used to initialize the data members of new objects generally. The constructor in C++ has the same name as the class or structure. Constructor is invoked at the time of object creation. It constructs the values i.e. provides data for the object which is why it is known as constructors.

Even the online Ruby documentation states, "Whenever Ruby creates a new object, it looks for a method named initialize and executes it." Even here, ruby-doc admits that the Initialize method is invoked when any class is created. And yes, this is true for C++, though again C++'s constructor is part of the class name.
https://ruby-doc.org/docs/ruby-doc-bundl...ation.html

One could consider it appearing thus:

RUBY:

class Fruit
def initialize(kind, condition, fee)
...

C++

class Fruit
{ int kind;
int condition;
double fee;
fruit()
...
}

Similar, but different. Also note the intuitiveness of Ruby that you need not immediately declare the data-types of the variables as you do with C++ and other languages. But that's another topic.

● ● ●

Now that the discussion of the existence of the constructor and how it is immediately invoked when a Class object is created, it is now time for discussion on their use. The previous talk was prologue to discuss what the Initialize method actually was. And now, for its base execution.

Since the initialize method is the built-in constructor method for all Class objects, it is not so much an inherited method as it is a hidden method. So it is subject to the alias or alias_method commands as any normal method, this without baggage of parent_class/child_class inheritance. Even if a script which you may have encountered does not appear to have initialize methods within their Class objects, they exist none-the-less.

EXAMPLE TEST SCRIPTS:

RPGMaker XP Test

Place below Scene_Debug and above Main

Code:
#==============================================================================

class Scene_Title

  #--------------------------------------------------------------------------

  alias scene_title_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_title_initialize

  end

end

#==============================================================================

class Scene_Map

  #--------------------------------------------------------------------------

  alias scene_map_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_map_initialize

  end

end

#==============================================================================

class Scene_Item

  #--------------------------------------------------------------------------

  alias scene_item_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_item_initialize

  end

end

#==============================================================================

class Scene_End

  #--------------------------------------------------------------------------

  alias scene_end_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_end_initialize

  end

end

#==============================================================================

class Scene_Battle

  #--------------------------------------------------------------------------

  alias scene_battle_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_battle_initialize

  end

end

#==============================================================================

class Scene_Shop

  #--------------------------------------------------------------------------

  alias scene_shop_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_shop_initialize

  end

end

#==============================================================================

class Scene_Name

  #--------------------------------------------------------------------------

  alias scene_name_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_name_initialize

  end

end

#==============================================================================

class Scene_Gameover

  #--------------------------------------------------------------------------

  alias scene_gameover_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_gameover_initialize

  end

end

#==============================================================================

class Scene_Debug

  #--------------------------------------------------------------------------

  alias scene_debug_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_debug_initialize

  end

end

RPGMaker VX/Ace Test

Place below Scene_Gameover and above Main

Code:
#==============================================================================

class Scene_Title < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_title_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_title_initialize

  end

end

#==============================================================================

class Scene_Map < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_map_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_map_initialize

  end

end

#==============================================================================

class Scene_Item < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_item_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_item_initialize

  end

end

#==============================================================================

class Scene_End < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_end_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_end_initialize

  end

end

#==============================================================================

class Scene_Shop < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_shop_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_shop_initialize

  end

end

#==============================================================================

class Scene_Name < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_name_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_name_initialize

  end

end

#==============================================================================

class Scene_Debug < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_debug_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_debug_initialize

  end

end

#==============================================================================

class Scene_Battle < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_battle_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_battle_initialize

  end

end

#==============================================================================

class Scene_Gameover < Scene_Base

  #--------------------------------------------------------------------------

  alias scene_gameover_initialize initialize

  #--------------------------------------------------------------------------

  def initialize

    p "I am initializing " + (self.type).to_s

    scene_gameover_initialize

  end

end

Notice the use of (self.type) in the example. Self is, itself, a keyword in ruby that grants you access to the current object, or a pointer to the current object if you wish to use C++ vernacular. The use of self in this instanceallows you to access the class object itself within the statement, while the .type method permits access to the name (or type) of the Class Object. The 'type' instance method is part of the innate Object class structure, and is connected to the 'kind_of? ' (aka 'is_a?') instance methods of the Object class as well. Object is itself a structure within Ruby and other Object Oriented Programming and encapsulates modules, classes and the like... a separate topic on hierarchy itself.

These examples apply simple messages whereby the classes rely upon the pre-defined initialize methods and do not have any defined by RPGMaker. So there are no message pops within "Scene_Skill" as it has a defined initialize method. But you will see message pops when exiting any menu to enter any map, the "Scene_Map" class utilizing its already existing constructor.

Ergo, the supplied example scripts can illustrate that the default initialize methods do exist within all Classes, even when undefined. And the use of the alias methods within the example scripts reveal their existence.

But this discussion is not about the use of Alias in itself. This discussion is about constructors and the initialize method. The use of Alias is another conversation of its own.

● ● ●

Now C++ does include another built in feature within the Class Object, it being destructors. Destructors too are predefined methods, their primary purpose to handle the removal of the objects when the Class object ends. And they too are built into Ruby, but not related to the dispose method and is not subject to alias.

That constructors and destructors are predefined within Ruby and C++ grants the coder more flexibility and means they have no need to invoke or define them (utilizing def within Ruby) within their custom Class code.

Steam on Linux & RPG Maker Series

Tue, 21 Feb 2023 21:59:08 +0000

Steam on Linux & RPG Maker Series

This is intended only for the RGSS based (a Ruby DSL) editions of the RPG Maker Series.

RMMV already features native support for Linux.

Don't ask me about RMMZ, I've never purchased it.

There have been very few cases where this has also happened to some people on Windows.

In such cases, you could simply skip all the Proton steps and go straight to the registry keys section.

When the day came that my PC crashed, I had to face a difficult situation. How would I recover from it?
Obviously, Steam always let you install your software at your request again and again.
This is quite a relief, right?

Yet, what happens when you reinstall RMXP or RMVX or even RMVX Ace?
Yes, guys, it can be mind numbing for it often tells you that it cannot find the corresponding RTP on your machine.

So what is the RTP?

It means Run Time Package, something that seemed to be quite convenient back in the 90's and 2000's. Think about slow internet connections, so slow that it would have been impossible for many people to use facetime or zoom.

Why does it matter?

It does mainly because the engine will NOT get fully displayed on screen otherwise. It would simply tell you that it could not find it and close immediately after you click on the only button available there.

So how do you solve that issue?

The solution that worked in my case was to add a registry to Proton, Steam's custom version of the Wine emulator.

How do I add the registry there?

By installing winetricks and then protontricks on Linux.

Then you can open the registry editor.

Code:
protontricks APPID regedit

Where do I get the APPID?

Inside any of your Maker's directories you can find a file called steam_appid.txt , just open it to copy it.
It is important because it will not let you open regedit otherwise.

It will take some time to get it open and populated with registry keys.
Once it is done processing them, import a new registry key.
The filename does not really matter as long as its file extension is reg as in file.reg

Keep it in a safe place just in case you ever need it again.

Now let us talk about the file's actual contents: the registry keys!

NOTES:

USERNAME stands for your actual username in Linux, no matter which distro you have installed on your desktop or laptop.
If you have installed your engines in custom directories, you will need to modify the strings accordingly.
The "RPGVX" string used below twice might need to be replaced with "RPG Maker VX" like in my case, but this might still be optional.

Code:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Enterbrain\RGSS\RTP]

"RPGXP"="Z:\\home\\USERNAME\\.local\\share\\Steam\\steamapps\\common\\RPGXP\\rtp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Enterbrain\RGSS\RTP]

"RPGXP"="Z:\\home\\USERNAMEkyonides\\.local\\share\\Steam\\steamapps\\common\\RPGXP\\rtp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Enterbrain\RGSS2\RTP]

"RPGVX"="Z:\\home\\USERNAME\\.local\\share\\Steam\\steamapps\\common\\RPG Maker VX\\rtp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Enterbrain\RGSS2\RTP]

"RPGVX"="Z:\\home\\USERNAME\\.local\\share\\Steam\\steamapps\\common\\RPG Maker VX\\rtp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Enterbrain\RGSS3\RTP]

"RPGVXAce"="Z:\\home\\USERNAME\\.local\\share\\Steam\\steamapps\\common\\RPGVXAce\\rtp"

[HKEY_LOCAL_MACHINE\SOFTWARE\Enterbrain\RGSS3\RTP]

"RPGVXAce"="Z:\\home\\USERNAME\\.local\\share\\Steam\\steamapps\\common\\RPGVXAce\\rtp"

Usually, this might not work right out of the box. Why are you surprised?
Don't worry! You might still need to reboot your PC and then any of them might open without causing you any more issues.

Of course, there is a chance you might need to install the RTP's via Wine.
Or you could purchase any of those engines while they are on sale on the official website.

Distance and Absolute Value

Sat, 28 Jan 2023 07:34:31 +0000

Distance and Absolute Value

This topic is pretends to help a future generation of game making developers or even future programmers and scripters and coders.

Our main question is how do I measure the distance between point A and B?

So let's go back to 7th grade stuff here.

The calculation can done by adding the Distance of the X coordinate and the Distance of the Y coordinate.

In some countries they would use the following notation to declare that they are using absolute values on a piece of paper.

Code:
|a - b| = |b - a|

# Example 1

|5 - 2| = |3| = 3

# Example 2

|-2 - 5| = |-7| = 7

# Example 3

|3 -(-2)| = |3 + 2| = |5| = 5

In Ruby and RGSS it would look like this:

Code:
dx = (x1 - x2).abs #=> Integer

dy = (y1 - y2).abs #=> Integer

d  = (dx + dy).abs #=> Integer

The pipes there are a symbol for the absolute value, that will end up being used as distance, but in Ruby you would call the abs method instead.

Integer there is a placeholder for a positive value, in this case there are no decimals nor fractions involved.

#=> is just a Rubyist's way to tell you what might be its return value from a human perspective without executing that part of the code.

# marks the beginning of a inline comment.

The equation tells us that no matter which one you subtract from the other value, the absolute value remains the same and will always be positive. So if you get as a result -7 or 7, the real distance will always be 7.

You only use the negative value as a way to tell the player or game dev if the direction is negative.

How does that translate to RGSS or even JS in the RM series?

It's quite simple. -X means to the left hand side while -Y will always be to the upper border of the game window.

If you just need either the distance on the X or Y axis, you gotta skip the third line of code then.

Well, I'm leaving here some interesting read for geeks just in case they care about weird programming stuff.

Content Hidden

Linux Kernel's Case Insensitive Hidden Feature

Sat, 28 Jan 2023 06:39:46 +0000

Using the Linux kernel's Case-insensitive feature in Ext4

First of all, I want to explain why it could slightly matter to you, especially as a developer not just for developing games but programming in general.

So far all Linux systems tend to use a case sensitive filesystem, even if they're dozens of FS available out there, and whenever a Windows user or programmer creates a file, they might not care about a filename's case at all for Windows simply treats all strings the same under that specific situation.

The link above will tell you about a couple of Linux tools and commands that will let you create a brand new filesystem that doesn't care about your typing style at all.

Here you can find a special mention here. If you can't get a "supported" return message from it, you should stop right there before you wind up messing with your filesystem and have to fall back to your default Linux kernel configuration.

Code:
cat /sys/fs/ext4/features/casefold

RPG Developer Bakin: Material Albedo (with C# script)

Thu, 19 Jan 2023 03:59:38 +0000

Change Material Albedos!

In this video, Bakin scripter Jagonz shows how to take characters in Bakin and apply any number of set albedo changed!

Here's a link to a more detailed description of the script, what event variables would be changed in the editor, and the direct implications of a script like this in your game!

Material Albedo Change (Itch site)

Smile Game Builder: Octopath Traveler Series by Jacob - DrassRay of Drattzy Games!

Sat, 14 Jan 2023 19:31:52 +0000

If you're stoked about Alterium Shift, and want to make your own pixelish 2D-HD RPG, this is the tutorial series for you! Hosted by DrassRay, this video series goes step by step on how to create a 3d version of your tilesets.

Video: Octopath Traveler Tutorial Series Introduction

In this tutorial, Jacob talks about software, the assets, and other things you'll need to begin creating your 3d maps.

Octopath Traveler Series Tutorials: Part 1 - Terrains

Welcome to part 1 of the Octopath Traveler Tutorial Series for Smile Game Builder, Blender, and Unity. This part covers terrain conversion from 2D pixel art to Terrain textures for Smile Game Builder.

Octopath Traveler Tutorial Series - Part 2 - Characters

In this tutorial, Jacob goes over the various characters, and how to create all the poses and more that you might want for your characters in Smile Game Builder.

Octopath Traveler Tutorial Series - Part 3 - Simple Box and Barrel

This part of the Tutorial covers using pixel art as textures for creating a box and barrel object. Smile Game Builder. A basic introduction to Blender is used here too!

Octopath Traveler Tutorial Series - Part 4 - Tree Animations!

This part of the Tutorial covers creating a Tree object with animations in blender that can also apply to other objects like grass..

Octopath Traveler Tutorial Series - Part 5 House Exteriors

This part of the Tutorial covers creating a basic House Exterior object using pixel art as a texture.

And that's just a FEW of the cool tutorials on how to make great objects for your Smile Game Builder to create a pixel style 2DHD game like Octopath Traveler. Now, if you want to get into the more intiricate models like bookshelves, beds, furnishings and more, be sure to check out DrassRay's Playlist called

Let's make a 2.5D JRPG

This tutorial series goes into more depth regarding creating furnishings and other stuff for your JRPG using SGB - Smile Game Builder or RPG Developer Bakin!

RPG Developer Bakin: The Active Timed Battle System Tutorial

Mon, 09 Jan 2023 03:36:55 +0000

Active Timed Battle System Tutorial

This time from Majestic Studio SC, we have an easy event-driven tutorial on how to get an active timed battle system to work for your battles in Bakin. Spice up your battles. Coked-out Kobolds? Drowsy Dragon whelps? Heroes that just crossed over into hyper mode and are flying at their enemies like a spider monkey? All this and more!

Here's how that looks in game too!

RPG Developer Bakin: The Layout Tool

Mon, 09 Jan 2023 03:23:09 +0000

The Layout Tool Tutorial Vault!

One of my friends over at the Smileboom official Discord, StudioBadGuy, created a set of videos to help explain the Menu Layout and Windows tools for RPG Devloper Bakin. I went ahead and compiled the videos here for your perusal!

Part 1: The Title Screen

Part II: Animated Title Screens

Part III: Menu Frames and Windows

RPG Developer Bakin: Button Press Graphic Change

Fri, 06 Jan 2023 02:19:31 +0000

Button Press Graphic Change

Originally created by MelonToucan

In this video tutorial, we'll show you how to create buttons on screen, check to see if those buttons are being pressed, and change the graphics accordingly. This also helps open the doors to AmalgamAshes' "Lands of Extensia" plugins, and converting those from Smile Game Builder to Bakin.

(And for those of you who don't want to try to do this yourself, I'll be uploading a .txt file and some basic graphics soon that you can simply IMPORT into your Bakin project to grab, expand and enjoy the new plugin!)

Tutorial: How to create a minimap in Smile Game Builder

Wed, 11 May 2022 22:27:49 +0000

(copied from "The Oceans Will Have Us All")

Hi, I'm going to do a few tutorials in Smile Game Builder showing some of the tricks I've used in The Ocean Will Have Us All.
If you have trouble seeing any of the images try right clicking and selecting "open image in new tab."

First up, here's how to make a simple mini map in SGB.

Load up the map you want to create a mini map for.
Oh look, we already have a little map there. That's handy. Let's use that.
Take a screenshot and crop it down to just the minimap

Step 2
Resize your cropped image to match the size of your map. We want it at the scale of 1 block: 1 pixel.

So the map I'm using here is 11 by 20 blocks (you can find this in the map settings) so I resize the image to 11x20 pixels. Make sure to use "nearest neighbour" resizing.]

The image is very small. We could zoom the image in SGB, however it will use a blurry bicubic resizing algorithm. I prefer sharp, clear pixels so let's resize it in our image editing software.
I've resized this one by 400%. Make sure to use "nearest neighbour."

I've then also converted it to greyscale (optional.) Save your map image to a folder.

Step 3.

Create a one colour dot image. If you've resized your image to 400% create a 4x4 pixel image.

Save this into your folder with the map.

Step 4.
Import the images into SGB.