Download    Games    Demos    Tutorials    Screenshots    Forum    Testimonials    Help   

Creating Games with Game Editor/Chapter 3

From Game Editor

Jump to: navigation, search

Understanding Actors

By now you should have a general idea of how Game Editor works. By using actors, you can build the elements of your game and assign actions to them. In Chapter 2, we built a game using actors for the main character, scenery, obstacles, projectiles, and various other things. We did all this with just a single actor type. Though the "Normal" actor type may be the most versatile, Game Editor has four actor types available.


  • Normal
  • Canvas
  • Wire Frame Region
  • Filled Region


Actors are the core of the Game Editor environment. Without them, you cannot make a game. Actors are object based code within Game Editor that can receive events and allow for the easy creation of a game. The editor environment is based on an event driven system in which these actors are assigned certain reactions to the environmental cues, talked about in the next chapter. You have already seen what actors are capable of, but that is only the beginning. There are the four main actor types you can create, but overall there are seven types of actors you will be concerned with. You already know the normal actor type, but it breaks down into three subcategories, the default, text actors, and tile actors. These three subtypes alone allow for the makings of many games. The default is the tool to make your characters come to life. Since the normal actor type can be assigned animations, unlike any other type, it is by far the most used. Game Editor allows for a quick level creator using animations broken into tiles. If you give the actor an image, you can use it to create an entire level with ease. The text is a quick and easy way of telling a story, explaining controls, and anything else. Canvas is the only other visual based actor, but unlike default, it allows you to create images through custom functions. With this ability, it makes for a very powerful tool in advanced game making. The wire frame region is just as it sounds, a framed region. This is especially good for establishing boundaries and detecting collisions. It is very efficient in cleaning up projectiles and any other actors that will go astray. It can also be used for camera manipulation and many other things. The last creatable actor type is the filled region. This along with canvas are not often used, as it can be avoided, but there comes a time in many games where knowing how to use the filled region can save a lot of time and pain. By far the most common use for the filled region is for clicking. This actor allows for the detection of mouse clicks, among other things, and can calculate the xy positions allowing for more control in your game. It can overcome many problems that may find there way into your game, such as zdepth. The very last actor is the view. Though this is not a creatable actor type, it is by far the most helpful. Without the view, there would be no display. In this chapter you will see the use of all of these actors along with descriptions for each one. All of these actor types can receive events making them all worthwhile tools not to be overlooked.


Each one of these actors have certain uses that they are better suited for, each allowing to add a new aspect to your game. This is not to say that they are limited to one use. Like the previous chapter, we will build a game to help further your skills and understanding.


The Platformer

Platformers are one of the most commonly created game types by Game Editor users. The game play can vary from simple to extremely challenging, and the replay value is like that of most arcade games. Plaformers can contain elements of puzzle games, fighting games, and many other game genres, making them extremely fun. The main objective is to go through a series of levels, in some case to fight a boss. Though platformers are usually mechanically simple games, a lot can be learned from making one.


It is always helpful to sketch out elements of your game before starting. Since we are learning about the different actor types, I will pair the main elements with its actor type.


Game Elements

  • Levels – Tile
  • Character – Normal
  • Character Movement - Wire Frame Region
  • HP – Canvas
  • Menu – Text and Filled Region
  • Obstacles/Enemies – Normal


Like before, this is the base of a game, where you can later make other levels, and improve it as you wish. We will be making one level for this platformer. In the next chapter, we will be using this game as a base to make a fighting game.


Levels The makeup of the level can make or break a game. The level is comprised of anything the player can see. Though there is the physical aspect of the level, there are many more layers to it. You want to have multiple environments and new obstacles as you play the game, or the repetition will get the better of the player. Another thing to keep in mind is if your player learns a new ability, make them test the ability and learn to master it, show them its true potential. If your game is only a flat strip of land in which the player must get across, that wouldn't be very fun, so make it exciting, add some adventure. Some ways to spice up the game play is to add puzzles, near impossible jumps, and anything that can test the players abilities and knowledge of the game. When making your level you should think of the character's abilities, how high they jump, how far, and how quick they can dodge. Another thing to think about is how many things are going on at once. If you pause a good platformer, almost always will you see several things happening. If the screen is moving then the player has something to do. With these things in mind, we are almost ready to begin.


Since we are starting with the basic level's makeup, we will begin by creating an actor that will act as the ground. For this job, you probably want to make the floor actor visible, not necessary, but it would be nice if the player could see the ground. This fact alone has narrowed our choice of actors down to two. If you have used Game Editor for awhile, you most likely will have narrowed your choices down to one. The only two choices left are: Normal and Canvas. If you remember, I broke normal into several categories; default, text, and tile. Here is a little explanation of each of these 'four' actor types in relation to the task at hand.


Normal-Default

  • Since we want to build the base of our level, the ground you walk on, we will need to either create an animation that encompasses the entire level, which can become very big, or we need to make many different actors each holding elements of the level, breaking it apart. Now this is possible and depending on what you are looking for, it may be optimal, but for most platformers it would be even better if we can build the level as we go, while keeping it uniform. Another big problem with using this method is it requires many actors, which is not a strain on Game Editor, but rather the amount of time required for coding. For each new actor, there is a new event required for collision recognition, unless you use clones, which then becomes a problem of movement. For this, default is is not the best choice.


Normal-Text

  • Text is not exactly what we are looking for, you may agree. Though you may think that it is foolish even to consider the use of text to build a level, it is not that far off. Text actors can take too forms of text, either true type fonts, or images that are broken into the ascii chart. Since you can use exterior images, you can make your own font that works as a tile system, but why would you do this if there is a tile system already built into Game Editor? Another problem with this is that collisions no longer work if the actor is a text actor. This can be combined with Wire Frame but why bother?


Normal-Tile

  • I will tell you now, this one is the optimal choice for making the base of a level. This combined with the default is all you will need to make your level. The tile system is a great easy to use system that not only allows for quick level creation but detailed work as well. By giving your normal actor an animation, you can then click the tile button, entering the tile building system. All you need to do is click where you want the tiles. Since you can make your own, you can cycle through as many tiles as you have made and make very detailed maps. Since all this requires is a single actor, the collision system will be loads easier than using just the default actor. One actor means one event for basic collisions.


Canvas

  • Now this is the last possible choice and by far the hardest to set up a professional looking level. Canvas takes practice to get used to, and it can really use up your processing. To use a canvas the size of an entire level would take up a lot of processing, assuming you are regulating it. If not, it still requires the directions built in to draw your level. Systems have been made to do this, but as said before tiles are much more efficient.


Now that we determined which actor type we will use we need to know how to use it. To do this, we must first understand how the tile actor works. But before we can even do this, Game Editor's way of handling animations must be explained.


<!> (Necessary?) Animations First, the only actor type that accepts animations is the normal actor. To be more specific, actors that are tiles or the default. Text actors cannot hold animations, since they have their own 'animation', text. In the previous chapter you added several animations, several even multiframed. Those were used as a series of separate images indexed by name. This is one of several methods available for animations. Game Editor takes many image types including but not limited to png, jpg, and gif. The three ways to make animations is to use indexed image names, use a animated gif, or use a single image that is chopped by Game Editor. All work efficiently, gif being the most disadvantaged. Another feature of the animation system is that for pngs and jpgs, the top left pixel becomes the alpha channel, that is to say becomes transparent. Now when you have an image, you may split it into horizontal and or vertical frames. This feature cuts up the image into equal sized frames, the first frame being the top left 'frame'. <!>


The relevance being, how you are going to use this image as your tile base. You are free to use any image or tile sheet, but this demo will stick to the one found <!>. Now it should already cut the image into the proper frames when adding the animation. Now that you have the actor ready, click the button Tile on the actor panel. This will prompt you for single tile or tile matching; pick single tile. This allows you to place individual tiles however you please. To use this, all you must do is click the where you want to place a tile. Now there are a few key shortcuts you should know. If you need to delete certain tiles, while you are editing, hold right shift. This will now set click to delete tiles as long as the key is pressed. Another important one is right control. If you run out of space in your current view, hold right control and click to gain hold of the stage. You can now drag the stage to the left, right, wherever you want. But by far the most helpful right now is clicking left shift. This will help lock your tiles into place side by side. If you don't get what that means, try it, it will be loads easier than trying to adjust your mouse over and over. Click it again to toggle this off. Now I will leave most of the level creating to you, with only certain rules set forth. These tiles that you place are only those that the player can stand on, hit, or in anyway physically touch them. There should always be sufficient tiles to be able to get across the entire level. Do not make the required jumps to high or too far. The tiles should always stay within the up down limit of the view, at least for this demo. You should add a few pits that allow the player to fall through to their demise. Just remember, you want the level to be fun for those playing.


Here is what my first level looks like so far.


Notice that my background is not black. This can be done by clicking on the Config button on the MainMenu bar. When you click it, you will notice a black square near the bottom. By clicking this you can change the background to the color of your choice.


Now this again is the basic level. We will be adding another actor also operating as a tile actor. This will be the background, which remains untouched by the player. These separate tile actors are used to add a dynamic effect to your game. It gives not only a sense of depth but keeps the players eyes looking at new things. Even if parts of your level are strait forward, you can have dynamic backgrounds and foregrounds. To do this you must create an actor and go through the process of adding tiles. Now on the Actor Panel, there is a slider for zdepth. As it sounds this slider effects the z positioning in the stage. The higher zdepth is the higher the priority, meaning sliding it to the right will make the actor come forward. Since you are at least doing a background, you would slide it to the left. If you want you can also make a foreground actor, also unreachable, for this, slide the zdepth to the right. Now you have built your first level, congratulations.


Now a level is not much if you can't explore, so we move on to the main character. Again we will use a normal type actor, but this time we will not use tiles. This actor will show you only a fraction of what the normal actor is capable of, but for now it will do. As I said before <!> the moveset is very important to the success of a platformer.


Abilities that our character will have

  • 0 – Stand facing right
  • 1 – Stand facing left
  • 2 – Run to the right
  • 3 – Run to the left


Now you may ask why I presented it like this but it may become clear. Though the left right description may seem redundant, telling a computer to do something can be tricky, the commands need to be specific. A bug will come up while you are making games with similar mechanics to platformers. This bug involves inaccurate animations for the actors given state, moonwalking. An example is moving left while showing the animation running right. There are three major ways of fixing this which are discussed at length in chapter <!>. For this game we will not fix this bug for simplicity, unless you go to page <!>. There you will find the step by step abbrieveated tutorials. A tutorial for this game with antimoonwalking should be there. For those like me who prefer to bypass this problem all together or if you ever find moonwalking in this demo to hard to deal with, I suggest looking at the page, you can either read up on it on either page <!> or chapter <!>, or use the ged supplied with the book named <!>. The moveset will also be a little more advance than the one here, such as jump animations and other.



If you haven't already, make an actor, and in my case I have named it Bob. Bob is a stick figure with a full set of animations for this task found <!>. If you want to make your own animations before starting, I suggest you first look at <!>. It has some very helpful advice that can cut the amount of work you do in half. Since we already know what animations or moveset our player will have, and if you are using Bob's animations, you can add all of the animations right now. Now if you did not add the stand facing right animation last, I would suggest you set the animation to that. This setting shows which of the animations the actor has on creation, and if it is running, that would be moonwalking.


Okay, now that Bob has his animations, we can begin bringing him to life. The first thing I would do is add the influence of gravity. To do this we will be using yvelocity and the draw event combined with script editor.


Script Edtior: Bob -> Draw Actor 

yvelocity++;


It is as simple as that. Since Game Editor already has set varaibles such as yvelocity, all you need to do is use them. This event will be triggered every frame that Bob is drawn. That means he will be constantly accelerating, and if you try running your game, he will fly through the ground. This prompts me to the next event, which we will be setting up a collision with the ground. Not only is the version you are reading right now void of antimoonwalk code, but it is also simpler overall which gives room for more bugs. Anyway, to prevent Bob from falling through the ground, make a collision event with any side of tiles. Now I personally prefer solely using script editor as the result of an event. This is because any event can be done through use of script, all custom functions exist. This will help in organization and allows you to do a lot more. With that said, choose script editor and set up a physical response. To do this, click the variables/functions button near the bottom of the script editor. Find and click on PhysicalResponse. It will prompt you with four categories. Leave the first two alone and set the third to 0. That should be all so press add and once more to add the script.


Now that your actor doesn't keep falling through the ground, we can begin to consider movement. We will use a similr method as the previous chapter. Normally, moonwalking will limit our freedom of simplicity, but since our concern goes out to learning actors, we will keep it simple. Add these keydown events. As a reminder, you may insert the Game Editor functions by clicking the variables/functions button in the Script Editor. This will make use a lot easier.


Script Editor: Bob -> Key Down (right, At least one key is pressed, repeat) 

x+=8;
ChangeAnimation("Event Actor", "r_run", NO_CHANGE);


Script Editor: Bob -> Key Down (left, At least one key is pressed, repeat) 

x-=8;
ChangeAnimation("Event Actor", "l_run", NO_CHANGE);


A lesson to be learned by scripts as simple as these is the fact that the ChangeAnimation function uses NO_CHANGE at the ending. What this does is prevent a constant repeat. Since the keydown has repeat enabled, it will run the script every frame if the key is pressed. If the ChangeAnimation is set to its default, FORWARD, than the actor would never get past his first two frames.


Now that we have left and right movement, we still can't have our actor explore the level we have built. To do this, we need to have the view move along with Bob. Now this can be done with a new type of actor. So we will create multiple Wire frame regions. The number will depend, but for this style of platformer I am making two for simplicity.

Actor Name: stop_right

Actor Type: Wire frame region

Animations: None (Wire frame cannot take animations)

Parent: view


Actor Name: stop_left

Actor Type: Wire frame region

Animations: None (Wire frame cannot take animations)

Parent: view


Now you will see in a moment what these are for. Wire frame actors are invisible so they cannot hold animations. These actors are especially good for marking off boundaries and that is exactly what we are doing. These actors should be placed overlapping the sides of view, giving room on the inside for Bob to hit. They should look like this.

<!>Image<!>


What we are doing is setting the outsides that Bob cannot escape. Upon collision with these, the view will move, preventing Bob's escape from view. If you notice, with this idea, we will not prevent him from going above the view nor below, so if you have levels that bypass the dimensions as such, you would want to add stop_up and stop_down. The codes for these actors will be held in the collision events of Bob.


Script Editor: Bob -> Collision (Any Side of stop_right) 

view.x+=8;


Script Editor: Bob -> Collision (Any Side of stop_left) 

view.x-=8;


What this does is it will move the view at the same speed Bob moves, and since the boundaries are parented to the view, they will move with the view. Other actors could pull this job off, but it is much more convenient to use this method. Now Bob can explore your world... That is if you don't have any obstacles on the ground. But even before jumping, you may notice that if you stop moving, the actor's animation continues to run. We'll 'fix' this simply, but it still won't be perfect, but we are going for simplicity.


The actor should stop running if you release the movement keys, so that is exactly what we will do. Add these events


Script Editor: Bob -> Key Up (right) 

ChangeAnimation("Event Actor", "r_stand", FORWARD);


Script Editor: Bob -> Key Up (left) 

ChangeAnimation("Event Actor", "l_stand", FORWARD);


Now time to turn our attention to jumping. This is a simple thing to implement if you are not terribly concerned with animations like we are. Create a keydown event for your jump button, for this I will use z.


Script Editor: Bob -> Key Down (x, At least one key is pressed) 

yvelocity-=15;


That is all you really need to do. The keydown event with repeat disabled may prevent you from holding it down, but you can still jump multiple times. In appendix <!> you can find fixes for problems such as this. Now the moveset is complete. The task to do now is to insert an obstacle to make the game a little more interesting. We will be adding HP also, so the obstacle can deal damage. For this one, you could use tiles, but I will be using this to show another side of making levels, in which you don't need tiles. It is a simple obstacle, a spike ball. We will create an actor and add the animation. We can then clone it and place them wherever we want.

Actor Name: spike_ball

Actor Type: Normal

Animation: spike_ball.png

Frame: Single


Note these are not that fancy, but this shows the ability to clone actors with animation, allowing for placement throughout a level, or to create the level itself. Enemies are done in a similar style. Now, we need to add the health bar, but for this we won't use animations like the last chapter. Canvas is an actor type that works just as it sounds. With functions built into Game Editor, you can place pixels and draw lines to draw pretty much anything. You can erase and even save the canvas. So using this, we will have it draw our health.


Actor Name: health

Actor Type: Canvas

Animation: None (Canvas cannot take animations)


Now make it 120 pixels or so long and more than 15 tall. Here is a picture of what mine looks like. To change the size, click the corner of the frame and drag. You should also parent this actor to the view, so it stays with you. Anyway, use this code in the canvas's draw actor event.

Script Editor: health -> Draw Actor 

int i;
erase(0,0,0,1);
setpen(0,255,0,0,40);
for(i=0;i<15;i++)
{
  moveto(-1,i);
  lineto(HP-1,i);
}


Also, you must add a variable HP, otherwise an error will prevent you from adding the script.

Name: HP

Integer

Global

Array: No Size:

Save group:


This requires some scripting knowledge, really just for and declaring variables. The first line declares an integer, similar to that of the variable, HP, we declared, but it is temporary. The variable can only be seen by this script, and should be dumped when the script is done. The next thing to look at is the for statement. 


for(i=0;i<15;i++)


Here is what would look like in pseudo code. 


while (i<15)
 {do this code} i++


So pretty much it will do the code 15 times. Now since i is increasing, we can use it to change the placement of the y variable. That way it draws a line lower than the last line, allowing for a thicker line. As of now, you don't need to understand this, as it will be covered in later chapters, but it is a very handy tool. Another thing required to understand this code is what the functions do. The reason it starts and uses -1, is that if x is zero, a pixel is still shown, as (0,0) is the top left pixel.


These are four custom canvas functions that this code uses. I will explain them briefly, but for those who are interested, a description of all the drawing functions can be found at page <!>.


The first is erase(). This function takes a color, the first three numbers, and then a transparency. Since it is at one, it completely wipes the canvas so we can't see it.


The setpen functions sets the canvas's pen to a certain color, transparency, and size.


The moveto places where the pen lies in comparison to the canvas's coordinates, not the real stage coordinates. We set the first one to -1 so that it does not draw any lines we don't want. If it was placed at 0, then we would end up seeing a pixel when we used lineto, even though HP is 0.


The lineto function will draw a line from the pens current location to the designated. This has HP-1 as the x variable, for the same reason as above.


Now in order for your actor to actually have health, add a create actor event for Bob setting HP to 100.


Script Editor: Bob -> Create Actor 

HP=100;


Now Bob has HP, but when he runs into the spike_ball clones, nothing happens. We will add a collision event that reduces HP.


Script Editor: Bob -> Collision (Any Side of spike_ball) 

HP=HP-1;
if(HP==0)
{
    DestroyActor("Event Actor");
}


The first part is what we decided on, but we need to consider what happens when you run out of life. The if statement checks if HP is equal to zero, essentially dead, and if it is, it destroys the actor. By now we have used all actor types except for Filled Region, and technically text, though text is only a sub actor.


Now, if the actor dies, the game is over. We could now choose to exit the game, or we could choose to restart it. We will use a text actor, combined with two filled regions to make the choice of either restarting, or of exiting the game. We will first start with the text actor.


Actor Name: restart_text

Actor Type: Normal

Animation: None (text actors don't have animations, instead they have text)


Now use whatever text you want, if you don't have one offhand, use the one from the previous demo. Now set the text to look similar to the following picture.


<!>Image<!>


Now set the transparency all the way to the right, 1, and the zdepth to around .75 Then parent the text actor to the view. Now we need to edit the death script, where we destroy Bob. Edit it to look like this.


Script Editor: Bob -> Collision (Any Side of spike_ball) 

HP=HP-1;
if(HP==0)
{
    DestroyActor("Event Actor");
    ChangeTransparency("restart_text", 0.0);
}


This will make your text appear when you lose. Now we need to make the player able to choose which option. Now we can add a mouse button down event on the text actor, but there are two things to consider. The first, how do we differentiate which one is clicked, and the second, you would need to actually click the text itself, which can be annoying. So what I suggest is to add two filled regions, name them different things.


Actor Name: exit_game

Actor Type: Filled Region

Animation: None (Filled Region do not hold animations)


Actor Name: restart_game

Actor Type: Filled Region

Animation: None (Filled Region do not hold animations)


Now place them over their respective text. You might need to make the text more visible for placement. Expand them to the size you deem acceptable as click range. You should set these actors' zdepth all the way to 1 and remember to parent them to view.


Now for the exit game filled region, we will add this mouse button down event.


Script Editor: exit_game -> Mouse Button Down (Left) 

if(HP==0)
{
    Exit Game();
}


And this one for restart_game. Note that these values are from my game. Right now there is not an easy way to reset the game, but later there will be. The values I used were ones that I got from my actors. This one is simply resetting all of the environment so that the game starts anew.


Script Editor: restart_game -> Mouse Button Down (Left) 

if(HP==0)
{
    CreateActor("Bob", "r_stand", "(none)", "(none)", -50, 107, true);
    ChangeTransparency("restart_text", 1.000000);
    view.x=-320;
    view.y=-240;
    HP=100;
}



And there you have it, a functioning platformer that uses all actor types. Each actor was demonstrated how you would see or use it in Game Editor, but do not take this as all the tricks the actors have to offer. Throughout the rest of the book, more and more capabilities will reveal themselves. Now for a recap, here is a description of each actor type.


Normal - Default

  • This actor is the most commonly used type out of all of them. This is due to their ability to hold animations and freely change between them. You have nothing if you don't have visual representation.

Normal - Text

  • The text actor as seen in this demo can hold text that is preset by typing it into the actor before game start. Now this may be a feature, but using scripting, you can manipulate the text to pretty much anything. Another common use not shown here is that of displaying numbers through use of textNumber.

Normal - Tile

  • Tiles are an extremely useful tool for building levels and much more. Though there are some disadvantages in using tiles, they can save a lot of time. These animated actors can help stack up professional looking worlds. Tiles creates single actor monoliths, an entire world with one click. This can save loads of time not just on the level creation, but the coding also.

Canvas

  • We only saw the bare bones of this actor, but through use of very basic scripting we could make a self supporting health bar. It uses its own functions to draw within the range as if it were just as it sounds, a canvas. Now that might not seem like much, but know now that with strong scripting knowledge, you can make some pretty cool effects.

Wire Frame Region

  • Now this actor may not seem as versatile as the first few, but their simplicity is quite an advantage. Marking off regions through simple means is quite a help when in production of large games. These invisible actors mark can mark off boundaries preventing free flying actors which can seriously slow down a game.

Filled Region

  • Now definitely this actor was shown the least. If you haven't worked a lot with menus, you won't see the importance of this actor. Due to the event environment and the allowance of zdepth, sometimes the clicking of actors can become muddled and end up not working. With this and a few tricks, you can prevent any of that from happening.



In this, we did use clones which are independently similar actors, spike_ball, but I did not go into the uses of them. In the previous chapter we used them in the same way, but there are many tricks to using clones. One thing to note is the ability to create a level with clones. Now tiles are better in the sense that they are a single actor that moves as one. Clones can create giant levels by clicking the clone button. If you do so, choose array. With this you can clone lines or blocks of your actor, similar to the tile level. Another problem with this is the cleanup. If you change your mind about having the actor, you will have to destroy each one.


Game Attachment

File:CGWGE Ch3 simple.zip

Retrieved from "http://game-editor.com/Creating_Games_with_Game_Editor/Chapter_3"