Tuesday, March 12, 2013

Creating Conversation

I know its been a while since my last post (things have been quite hectic). I'm close to getting an alpha done and I had to change the complete back-end of my game to match up to a new requirement that may or may not change. To get to the possible change, some background info is needed on the first back-end and the one I currently have.

The back-end I am referring to is to simulate conversation flow in a non linear way. In a typical dating sim, conversation is quite linear. You have a selection of choices to either ask the character or respond to (usually 4). There is usually one right answer. If you get the right answer the game continues and another set of choices of either questions or responses until the game is complete. Obviously this is not realistic to reality.

A typical conversation flow in dating sim.

As you can see in the first depth after the intro, each response to the intro can bring up a  different set of questions or responses based upon what question or how you responded. Then each branch delves linearly to a set question/response that must be answered in order to progress. This kind of non-linearity is closer to what a real conversation is and what I hope to simulate when the project is over. 

In order to achieve this non-linearity, a more generic tree must be used. What better than a graph. The way the graph worked is that each Vertex in the graph is a conversation state (QUESTION, ASK, FOLLOW-UP). A QUESTION is a question you ask the character, an ASK is a question the character asks you, and a FOLLOW-UP is a response to your question or to the character question that can lead back to a QUESTION or ASK. 

A graph simulating the Conversation Graph

 Inside each state are several responses the character uses as an edge to either a QUESTION, ASK, or FOLLOW-UP state. It is a directed and weighted graph. The weights are the probability of a certain response being used. If time permits, I would love to create a probabilistic model of a certain result being asked in one situation and by a certain personality type. However, this may or may not go in depending on how much time I have to complete it.

As much as this model worked, and I even created a prototype for it, it didn't simulate the conversation in a way that my team thought was the best way. So we decided to go in a different direction. One of the most common aspects of conversation is that both partners mine for a common topic to talk about and delve deeper into that topic. So we decided to simulate that aspect of conversation. It works much like standard conversation flow above, in which a person "chooses" a topic by asking them a general question about it. It can then go deeper with them asking more personal questions about the topic until they choose to go to another topic, or the topic runs its course and another topic must be chosen.

A Topic Conversation map

Each iteration of each topic is a certain depth of the topic. Iteration 1 being a very general topic for example, "What is your favorite book." and the last iteration being something very specific, "How do you feel about the collected works of William Shakespeare." No matter how deep a person my be in conversation, they still have a chance to get out by asking an iteration 1 question from the other topics. Inside each iteration are a list of questions that the player may ask. Each question is generically similar such that each response in the response list could logically be used to answer any question posed. Once the response is stated, the conversation goes to the next iteration where they may choose to continue the conversation on the topic or move to a different topic.

Obviously this representation does simulate topic conversations, but it is still linear. When coming up with questions to fit this model, our designers found it really hard as they wanted tangents and two different iterations to account for that to add non-linearity. So far nothing has been changed, but if we want to still keep this model, but still add non-linearity, then a combination of the two models needs to be done.

A Hybrid Conversation Flow

Reaching a topic is the same as before, but the going through iterations is not so linear. Each iteration is the same as the old one; the only difference is that each response acts like the response in the graph that it acts as an edge to a new iteration. This time though, not only can a response map to the next iteration, but a different iteration in a different topic allowing the character to change the topic.

Each representation has its own strength and weakness, but I really like the third representation the best since it achieves what we want the best. The only reason I don't throw away my back-end and start anew is the fact that I would have to throw out my back-end and start a new and for the second time. Also, I have a Play-Test this coming Tuesday, so I don't want to have my game in a state of unplayability. Also I would hate to change out the back-end only to find out I need to stick with a previous representation or create a new representation for a completely new set of requirements. All I know is that conversation is tricky. I should post again about which representation I did as well as other aspects of the game (if I don't be lazy for a month again).

Sunday, February 3, 2013

Game Dev II and starting a Tech Demo

Its been a while since I lasted posted, but I have now gone into the full swing of things here in the Spring Semester. This semester, all of my classes are CS (except Game Dev II, but I program in it). Since the beginning of January to now, I just got put into a team of 8 to create an alternative game. We talk it over, and we decided to make a Dating Sim to help people with the social constructs of asking people out. This game will avoid all the cliches of Dating Sims you may have played online. For the first part, the game will not end in sex or anything related to sex. You have the internet for that.

Like last semester, I am the only programmer on my team. There is one other person who does know how to program and will help out where he can, but I have to do the heavy lifting. Normally I would be nervous, but a Dating Sim isn't too hard to program. Plus if I do get overwhelmed, then I do have someone to help me out too. There are somethings that I do want to do in order to make this game more than just your standard Dating Sim. Everyone on my team is researching topics on dating and that includes personality types. What I would like to do is establish a probability tree to the likelihood of a person of a certain personality reacting to questions of another personality. This in itself is complex and 3 months is hardly enough time to get the data to even start on a probability tree. However, I would like to get the ground work started, even if the numbers are a bit crooked, it would be interesting to have probability to your advances even if you are asking the same question that would work on another person. This add a bit of realism to the game and gives me something to do. With this, there isn't a certain path that you can take to get the girl, sometimes a certain girl just isn't that into you and I want this game to show it. What will probably really happen is a really simplistic version of my model. The challenge would be fun though.

With that in mind, I couldn't start the whole Bayesian probability just yet. I had to work on getting the basics of Dating Sim to work. This includes going from place to place (different locations), being able to initiate conversation and have the person ask you a question and having x choices to make on what to say back. These are all button actions and aren't that hard. However I am using Unity which is a lot nicer than Gamemaker. For one Unity is in C# which is one of my favorite languages to use. With that in mind, I am using the free version which is limited with what you can do (a license costs about $1,200). What I needed to do was to make a nice button class that was generic. Unity does have a good button tool that allows great customisation  so I decided to create a wrapper class that would add on to the button to modify it how I needed it to modify based on what it is suppose to do. Then comes the problem with passing in variables. Unity classes are really more scripts in that it adds on to a pre-existing class when you create an object or prefab. So if you need to pass in a value you just create the variable as a global variable and in the editor, you can type in what value you want and experiment with it (even when the game is running which is nice). The problem lies when you want to pass in a variable or another object. The public variables recognize primitives and certain objects (such as GUI, GameObject, etc), but if you created a Linked_List, then it won't recognize that and won't let you pass anything in. Then if you do want to pass something in that is recognized, like an int, then you have to pass in an actual value. For example, I wanted to pass in an x based on the width on the screen which is (Screen.Width), but the editor only accepts certain letters and numbers, so I couldn't even pass in the variable. With that in mind I am searching for a way to pass in variables that way so I can position my buttons in a more precise way than "top-left", "bottom-right", etc.

Since I wanted to get something done, I was able to get buttons that would transport you from place to place with limited precision to where you can place the button. I was listening to some Lord of the Rings music (mostly the theme for the Shire and Rohan) and I decided instead the original placeholders (crappy anime backgrounds), I would have a Lord of the Rings theme and place in locations from that mythology. I then decided to place in what people you would try to hook up with. Since Lord of the Rings isn't known for its diversity, I decided to have the player hit on the Mouth of Sauron, Lord Denethor song of Ecthelion, King Theoden son of Thengel, Bilbo Baggins, and Elrond of Rivendell. Also the locations their from are the background. I just went from there adding in background music that the film had for their area. I wanted to add in dialogue and conversation buttons, but I decided to stop there for the night and carry on. I really want to carry on with this, but my team probably won't let me (I can't blame them either). But at least I'm closer to finishing a tech demo that can be used to showcase what game should be about.

Imagine the calm music of the shire playing in the background



Once you get past the madness, he's really a nice guy

He's single ladies. 



Saturday, December 22, 2012

Fallen: Closing Remarks

Well, I finally turned in the "final" version of Fallen (well, last week I was enjoying some rest). Final is in quotations because the version is really nothing more than a demo showing off the mechanics that we wanted to do. I can honestly say that I am satisfied with the product we were able to deliver, but disappointed that we couldn't release the full scale game that we wanted. That is mostly because of time. There just wasn't enough time to complete the full version with the resources we had. If we were to continue on with this project, it would probably take at least another semester of hard work, work I have to allocate elsewhere. As much as I would love to complete this game fully, I'm just too busy with school work and other projects for the next semester. We may pick this project up again during the summer break, but I don't know if we will carry through with these plans.

If we were to carry on the game, there would be a lot of things I would like to change but couldn't to keep consistency and stay on schedule with the completion of this version. The biggest thing I would like to change is the tool we use to build it. I would scrap Game Maker in a heart beat and use another language. I suggested Actionscript 3.0, but that was only to fit within the time I had. I would like to start this game from scratch again and use the lessons I learned making it to better improve the product. If I were to go all out on this game and assuming I had the resources and time to actually do it, I would love to have this game as an open world 3D RPG. This would require 3D artists and animators, the artist we have is an awesome 2D artist, but he will be the first to say that his 3D work is basically non-existent. I would like to recruit some more programmers on this task since the workload will be extremely heavy with a sufficiently large game that would be like any other RPG you've played (like Dragon Age). If we are keeping things to a pipe dream, then this game could be your next AAA game. So if I were able to have all those variable accounted for (some how), then the tool I would most likely use is a combination of C# and C++ most likely using the .NET framework and possibly UDK. If this game is to be scaled back drastically, but able to keep the open world 3D aspect to it, then I would like to use UDK or Unity.

With that, this concludes the series on Fallen. You can download the demo here. I will take a rest for the rest of this year and pick up again, when next semester starts and I start the next Game Development course. The course focuses on Alternative Gaming, so it should be interesting what the result may bring and a chance to do something bearable this time without Game Maker. Who knows, only time will tell.

Monday, December 10, 2012

Beta and the Pit

I just had beta testing for Fallen and what an experience that was. You can test for all anomalies and bugs in your game, but only those who have never played your game will find the bugs. Users found two recurring bugs that I thought couldn't happen. The first bug was during a certain time when Vengeance was swinging his sword and the radius variable wouldn't initialize. I fully don't understand why that occurred, mostly because I couldn't step through the code and see what actually happens, but I was able to fix the bug by simply initializing the variable to just outside the range of a hit then have the code check for the actual range.

The second error was a variant of the sticky wall problem (where the character sticks to wall when the player walks and jumps straight into it). The player wouldn't stick into a wall, but if they were in contact with the wall and continued to press the space bar, then they could climb up the wall. This was a bit harder to fix, but I was able to fix it by creating a boolean to check if the player is jumping and have the player act appropriately when next to a wall based on that boolean.

The major complain that we did receive about the game was that the player didn't have a chance to use all the upgrades and fully traverse a tree since the full game is not complete. So we decided to create the Pit.

Pit mode is like any arena level or game where you start at a base level and waves of enemies come in at you. This does automatic upgrading when a person gets to the next level since the waves are continuous and the player can switch trees instantaneously. Initial responses to the new mode were favourable. The hardest part about creating the mode was random enemy generation and having enemies spawn at a pace that would start out easy, then get harder as the enemy progresses.

My method for enemy generation was to first create a range that would start out large at lower levels then get smaller and smaller as the player progressed. My initial formula to generate this range was Max_Level - Level;. So as the level grew, the range got closer to zero. This is still the formula I am using, but it is not optimal as I will show below. From the range, it would then pick a random number from [0, Range]. Then it will pick a smaller range by choosing a high and low number. It will choose the low number first by choosing a random number from [0, Range], then it will choose the high number by picking a random number from [low, Range]. Then it will check to see if the number is in the smaller range of numbers. If it is, then it will generate an enemy, if not then it will try again.

pseudo-code:

void generate_random_enemy()
{
      if(num_enemies < max_enemies)
      {
             var range = max_level - level;
             var valid_number = random(range);
             var low = random(range);
             var high = random_range(low, range);
             if(valid_number >= low && valid_number <= high)
             {
                   instance_create(obj_imp);

                   num_enemies++;
             }
      }
}


The problem with this algorithm is that even though there are many permutations, the computer can work through them extremely fast and enemies will still be generated at a fast rate. One thing that I do want to try is by playing around with the range and generating a new formula to get a better and larger range. Another thing is to have the algorithm sleep for a certain amount of time. So after it has generated an enemy or not, it will wait for x amount of time before it starts again and x will decrease as the level gets up. For now, I just limit how many enemies are spawned at a time, with the number of maximum enemies grow with the level.

Now that Beta is over, I have to work to get bugs finished and the game polished for it to be turned in by the end of this week. I will post one final time about this game with my final thoughts.

Sunday, November 25, 2012

Trees and Captain Crunch

This is a screenshot of your starting position when starting the game. 

Basically for the past week I was working on implementing the other two trees and finishing up their abilities. Mercy is 100% complete. Vengeance is 90% (I just have to wait on Cory, the artist, to send me the artwork for the final ability). I'm 50% done with Justice (a few more abilities and his artwork). With the final trees finished, the game will be feature complete. Then we can focus on enemies and levels.

Implementing the trees was a lot easier than I thought. It's just mostly copy and paste and replace certain values to the correct ones. In fact, it was when I was copying and pasting when I remembered the wise words of my Intro to CS professor. "If you find yourself copying and pasting over and over again. Just put it into a method."

This is the code to check if a certain ability is activated and set up and update the HUD to show that it is disables and display a circular timer to count down when the player can next use it.

var is_active;
is_active = ability_is_active("I_Crush");

if(is_active)
{
    draw_sprite_ext(spr_hud_keys_mercy_2, -1, 102, view_yview[0] + 12, 1, 1, 0, -1, alpha);
 
    origin_x = view_xview[0] + 50 + 76;
    origin_y = view_yview[0] + 36;
    radius = 25;
 
    if(instance_exists(obj_angel) and !obj_angel.canUseCrush)
    {
        per = obj_angel.alarm[3]/global.crush_cooldown;
     
        for(i = 0; i < 360 * per; i += 1)
        {
            radian = degtorad(i - 90);
            dst_x = origin_x + radius * cos(radian);
            dst_y = origin_y + radius * sin(radian);
     
            draw_set_alpha(.35);
            draw_set_color(c_black);
            draw_line(origin_x, origin_y, dst_x, dst_y);
        }
        draw_set_alpha(1);
    }
}


this can be changed to:

var is_active;
is_active = ability_is_active("I_Crush");

if(is_active)
{
         activate_ability(spr_hud_keys_mercy_2, view_xview[0] + 50 + 76, view_yview[0] + 36, obj_angel.canUseCrush, obj_angel.alarm[3], global.crush_cooldown);
}

activate_ability(player_sprite, origin_x, origin_y, ability_bool, angel_alarm, cooldown_timer, )
{

    draw_sprite_ext(player_sprite, -1, 102, view_yview[0] + 12, 1, 1, 0, -1, alpha);

    radius = 25;
 
    if(instance_exists(obj_angel) and !ability_bool)
    {
        per = angel_alarm/cooldown_timer;
     
        for(i = 0; i < 360 * per; i += 1)
        {
            radian = degtorad(i - 90);
            dst_x = origin_x + radius * cos(radian);
            dst_y = origin_y + radius * sin(radian);
     
            draw_set_alpha(.35);
            draw_set_color(c_black);
            draw_line(origin_x, origin_y, dst_x, dst_y);
        }
        draw_set_alpha(1);
    }
}


This greatly simplifies things and it was perhaps the first time that I actually got to use an actual programming paradigm to help me out and that Game Maker would actually allow. However, I still got to the problem of the actual timer. Game Maker only allows you to have 12 timer events per object. I need 15 for each tree. The first thing I tried was to simply have 5 and if the timer event was activated, it would reset the current tree's ability that it was associated with to true. Of course the problem with that is obvious. You can activate an ability in one tree that has a slower cooldown rate and then go to another tree and activate an ability that was associated with the same timer. The timer would reset and whichever tree you were on when the timer would go off would be reset and not the other (you could even be on the third and have neither reset). This is where Game Makers decision baffles me to limit the number of timers an object could have. Right now I am thinking of different approach that would only use single timer (kind of). The step event (an enter_frame for those who know actionscript 3.0) is sort of like that timer that goes on until it is disabled. After each step, the independent timers would count down and activate if their timer reached zero. All my timers do is if they reached zero is set a boolean to true.

The way Game Maker handles booleans is that 0 and NULL are false, everything else is true (whether it be ints, doubles, strings, and even objects). So have a timer variable that would keep track the time it had to cooldown. It would count down 1 every step (unless it was already zero). Only a single variable would therefore be needed to determine if an ability can be used or not. Take the timer variable and NOT it. 0 would be true and all other numbers would be false. This would greatly simplify things and free up excess timer events to be used elsewhere where more complex algorithms can use it.


This is a screen shot of the upgrade menu (made by me not a competent artist). This will list each ability both passive and active that you can get for each tree. 


That should be simple enough, then I realized that Beta is due in a week (December 3) and the finished title the week after that (December 10). Then the semester will finish out. All I can say is that this semester went quick. One of the big things that everyone says when a deadline is approaching is that they didn't have enough time to get the product they want. I can honestly say is that this game will not be the game we were hoping for at the beginning of the semester. I will have a more complete recap when the project is complete, but we seriously went over our heads thinking we could make an RPG platformer in a single semester. At the beginning of the semester, I knew we wouldn't be able to do everything but what we weren't able to accomplished astounded me.

There were several factors that led me to believe this could be done. The first is I thought Game Maker would be a simple tool to use and even though I wouldn't be able to achieve the depth I wanted I would at least be able to speed things up. I was wrong. The first problem is that I didn't learn the in's and out's of Game Maker and GML in the time that I thought and even when I did, past experience wasn't as helpful as I thought too because I had to abandon almost every programming paradigm since I started the program. The second is that the art took longer than expected (Cory even admitted to that). I needed some assets to play around with (I'm not that good of an artist so I couldn't have made any placeholders). This delayed production a bit as I struggled with GML to get even some simpler things working.

My biggest problem with GML is that the debugger is absolutely horrible. With event driven programming, using strings to detect problems can only do so much. I needed to step through the program to figure out what variables were at what time when I do certain events. The step that I couldn't step through was simply horrible.

That's all the gripe I have today. I'll probably post again after Beta.

Wednesday, November 7, 2012

Fallen: Artwork, Upgrade menu, and linked lists

Its been awhile since I last posted, but I've been really busy with school work and midterms. I haven't been able to focus as much as I wanted on Fallen for that reason and the fact that I have to wait for the artist to finish some assets. The artwork is going great and Cory Stivers is an awesome artist who can get some quality work done in a quick amount of time.


This is the concept for the angel.


These are the sprites of the angel for mercy. 
(Left: The attacking animation, Center: This is for walking, but the animation doesn't seem to be working, Right: the idle animation)



These three are the backgrounds for the first level. These don't include the Statue which acts as the platforms. 

Now that some good stuff is out of the way. What I did this past week and a half when I did have the time was create the Upgrade menu, pause ability, and a upper HUD to show which ability the player can use and what key it is mapped to. The upgrade menu was the hardest of it not because it was a challenge, but because game maker and GML is not like any normal programming language. 

The way the upgrade menu works is that there are three trees of abilities (Justice, Vengeance, and Mercy). Each point you get by leveling up, you can spend on an ability. You can purchase any ability on the tree, but you must have purchases the previous ability. So in order to get Justice level 2 ability, you must purchase the Justice level 1 ability. This should be easy to do, but the first thing that bugged me was laying out each button. Normally what I would do is utilize object-oriented programming by creating a master button that each subsequent button extends off of. Game Maker kind of does that, but it really is weird and doesn't act like a true super class, especially when it comes to overrides. What I decided to do is to create one button and to have parameters specify where it will be and what ability it would activate. Again this should be easy, but GML doesn't have a new Button() call. Instead what it does require when you want to create a new object is to call instance_create(x, y, obj). Parameters can't be used to customize it. What I had to do is the following code.

button = instance_create(x, y, obj);

with(button)
{
    //initialize button here
}

In GML, with acts like a for each loop. If you put in an object name, then it will loop through each object on the stage. If you put in an instance id, then it will just do the instance. This is very annoying because and code inside the with loop is called as if its inside the actual button. So a call of instance_destroy() inside the with loop is like button.instance_destroy(). However, you can't call button.instance_destroy() or any other methods to apply to an object. The only thing you can call from an object is a global variable. 

I was able to lay down the buttons and set them so that any ability that could be activated could be selected. Now came the second part. If the player decided to accumulate more than one point, then they could purchase multiple abilities down a tree. This required me to set up a system that would check to see if the previous button was selected so that if it was selected, then the current button could be selectable. This caused the problems. Each button has no knowledge of any other button, so I had to create a data structure that would host each button in sequential order so that the previous entry was the previous button. The obvious choice for me was a linked list. GML has no linked list. What it does have is a list that is similar to the ArrayList in java or a list in C# or a dynamic array (vector). So I create this list hoping that it would function the same as a linked list. To my surprise not only does GML list have no iterator. But when I did find a way to get the previous entry, the code to check to see if the previous was selected didn't work. No matter what I tried, I couldn't get the code the let the next selectable button to be selectable. 

Normally I would debug by stepping through the code, but GML doesn't have a step in functionality in its debugger and prints didn't tell me anything useful. I couldn't think of anything else to do, and I had to continue on the game and get it ready for the Alpha, so I dumped the functionality and just had to have the user select one upgrade at a time. I really hate game maker. Its reasons like this that I wished I had used actionscript 3.0 and flash to create the game. But I'm stuck with my decision and will have to trudge through the finish. 

Thursday, October 11, 2012

Platformer AI: Swarmmers

This past week has been very busy for me. I could get a chance to enjoy my Fall break and play some video games that are sitting on my shelf all alone, but instead I get to spend the week with Game Maker. I'm still developing a tech demo to show off to my professor that must be done by this upcoming Monday, so procrastination isn't an option. All I have up to this point is an angel that can move around and shoot fireballs (just one of many abilities) and the lowest enemy that a player can fight.

I actually did quite enjoy developing this enemy since it required me to do some actual thinking (not just looking at documentation online to make sure I did it right). This enemy is a lot more complicated than your average Goomba who walks back and forth all day. For this enemy, I had to implement basic physics and calculation to estimate trajectory and get from platform to platform. I will be using some advanced physics equations (what you would learn in an intro college physics class that required Calculus).

For clarification, this specific enemy is called an Imp.

The Imp is a not powerful and very weak. It works well in large numbers where it swarms their enemy by strength in numbers. What I needed to do was to create an enemy, that when the angel got into range it would swarm straight towards it. This is not as straight forward in a platformer with multiple platforms at different levels.

The Imps default mode is just to walk back and forth on its platform until the imp spots the angel.

When the Imp spots the angel it determine if the angel is above, below, or on the same level as the angel. The same level argument is easy enough as the Imp just charges by setting the x velocity towards the angel.

When the Imp is above the angel:


The image above shows what should happen in this situation (red denotes Imp, blue denotes Angel). The Imp needs to get from the top platform to the bottom, So either he can run off the edge or jump off. Running off might seem simpler but that does collide with the code that makes the Imp stay on the platform in his default mode. Jumping not only makes it easier for the Imp to get to the target, but it adds a more fluid and natural looks of a demon trying to get to its target in the fastest way possible. 

To find the initial velocity needed to clear the platform, it needs the distance (d) from it to the edge. From there the equation is: 


vi is the initial velocity that is needed, g is gravity and theta is 45 degrees (pi/4) because its the easiest to calculate and x velocity and y velocity are the same. Everything else besides vi is known so we just rearrange the formula to get: 


using vi, just plug in that number into x and y velocity and the imp will jump off the platform and land below where it can swarm the angel.

There are some things to be aware of and it is the negation of the values that are put into x and y. For example, vi can be a positive number but the y velocity needs to be negative because of how the Cartesian coordinate system is arranged by the language. 

When the Imp is below the angel:



This requires some more insight than the previous one. When the Imp was jumping off a platform, it could jump at 45 degree angel making the calculation easier. In this case, X and Y are independent of each each other except time (t). The vector at which the Imp jumps can range from 1 to 89 degrees. The angel at which the imp jumps is irrelevant if the x and y velocities are known. In order to figure out the velocity in which the imp must jump, we must find the minimum velocity to reach the height of the platform (h). 


 Since the y velocity when the Imp reaches its height will be zero, the equation can be rearranged to:


Knowing the initial y velocity, we can now find the initial x velocity. The only thing that x and y velocities share is that it will take the same amount of time to reach their destination. We can use that knowledge to get the x velocity so that the Imp can reach its distance (d). We can start with the most basic of physics equations, the kinematic equation to find position. Since x does not have an outside force on it, acceleration is zero and we get the equation: 


xf and xi subtracted is the difference (delta) x which in turn is distance:


Again using the kinematic equation for the y axis for velocity, we can represent the initial y velocity as:


Again knowing that final y velocity is zero, we can rearrange that equation as:


We can rearrange the x axis formula two above as:


Plugging t into the x axis formula, we get:

Using basic Algebra, we can rearrange this to be:

Now that we have an initial velocity, the Imp can now jump to the next platform. 

There are some problems with this implementation, and that is it does not take into account where the imp is and the dimensions of the platform. The imp can be below the platform and jump straight into it. The other problem is that the imp will always be one step behind. The hero can be jumping up several platforms and the imp will only know when it lands on the previous platforms. There are ways for the imp to follow the angel up the platform and anticipate where the angel will be using more advanced algorithms. For the moment, this algorithm is sufficient for a basic low level enemy and does provide some basic challenge above the walking back and forth goombas. At least the imp is trying. 

That is all while I finish to complete my tech demo and get the first level finished. Game Maker doesn't make it easy as well as I have to forget everything I learned as a CS major to get some things to work also a debugger that doesn't let you step through your code.