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.