Game Maker: Studio || Day 2 || Random Randomness and Sprite Implementation

     Today I tried working on the random movement for the dragger when it does not see the player. Sadly, I am having a few issues with that, so I don't know if I'll continue with the idea for right now. However, I managed to get the player sprites into the game, which is looking amazing.

     I tried many different methods of getting the random movement to work, but I just can't quite manage a success. It seems that the error would be in the variables; I am not setting them up quite right. The random movement seems only to work when the player is away from the dragger at the beginning of the game. This is due to the code being in the create event. With the code being in the create event, it works flawlessly giving the exact effect that I want in the game. However, when I try to put it into the step event it just makes the dragger run around wildly, rapidly changing directions and never stopping. I need to figure out a way to make it only happen every once in a while. Maybe using a counter variable with a long timer could solve this one.

     As for the player animations, they are looking phenomenal. I haven't been able to test out the death animation in game yet, because I can't seem to get the dragger to completely kill the player for some reason. I do have the running and idle animations in however, and they are working great. Now that I had the experience with the dragger animations, I knew a bit better on how to center everything exactly so that it didn't only look good in game, but it performed without causing any glitching into the walls or floor.

Tomorrow I will try to get the random movement fixed I think I will be able to get it to work with a bit of tweaking. If not, I will just scratch that idea until a later time. I do have one issue I could work on where if the dragger jumps into a ceiling, it gets stuck at that height with no gravity forcing it back down to the ground. I did try a quick fix that I mentioned last post, but it caused more problems so I just went on with my other business. It shouldn't be too hard to solve, so I think I could get it done if all else fails. 

Game Maker: Studio || Day 1 || Round Two of Development

     The second semester is upon us, and I am back in action. I have rejoined the infotech class, and I have already continued the development of the game. I have also been working over the break, and  I feel like I've made a ton of progress. Over the break, I decided to re-code the entire game. Yes, everything; and I'd have to say, the game is much better now than what we had before. I am still working in collaboration with the other guys. Jake is giving me artwork as we go, and I am implementing it into my game. You will see in later screenshots I already have the dragger sprites coded in. I also have the death animation working for it, so I can show that off at a later time. 

     Today in class, I worked on making the dragger's AI. The goal for it was to be able to track the player, as long as he is in the enemy's sights. I have  a few variables involved here that are making this work. There is one that tracks the x value of the player (instead of typing obj_Player.x all over the place), one that tracks the distance to the nearest wall, and one that gives the x value of the nearest wall object. I have been trying to get this to work for weeks now, but I finally figured it out.

     To get it to work, I needed to make a separate chunk of code for each situation the player and the enemy could be in. For example, there is one that checks if the player is on the right of the nearest wall, and if the enemy is on the left. If that is true, the enemy (currently) does nothing (I will make it move around randomly on its own soon). There is also one that checks to see if the player and the enemy are on the same side of the wall. If they are, the enemy tracks towards the player and tries to kill him.  There are different instances of this for if the player is on the left or right of the wall, as well as if the enemy is on the left or right of the wall. There are two copies of that; one that works based on if the enemy is a distance of 400 away from the nearest wall, and one that works if the enemy is within a distance of 400 from the nearest instance. That way, the enemy won't get stuck in between the walls, but will still detect if there is a wall between it and the player.  I am going to make the distance of 400 much shorter however, as it may cause some problems in the future for making small rooms and pit traps and whatnot that are smaller than 400 wide. 

Notable in the screenshot is that the enemy is getting stuck to the roof when it jumps into it. This will also be fixed in the future as I just need to make a simple fix by using some simple instance_nearest calculations.

if instance_nearest(obj_Floor).y>y{
collision=0;
y+=1;
}

     Now that the AI is done, all I need to do is actually make the enemy do something while it is not tracking the player. I also got a suggestion from Jake to slow down the rate at which the enemy is able to jump. Right now, it is just jumping again as soon as it touches back down on the ground. Tomorrow in class I will be working on the random movement. I think I have a text file of a test one that I wrote out. Since I never got the AI to work properly, I never got to test the random movement code. I'll try implementing that and seeing if it works. If I remember as well, I'll try to limit the jumping of the enemy. I also need to fix the sprites for the dragger so that when it is stopped, the walking animation does not play. I also will have some sprites for the player to be putting in soon as Jake finishes them. 

Day 75: Final Post... Probably

     This year in infotech has been a real journey. I have learned many important lessons throughout the semester, through mistakes of my own, and others around me. We all(mostly) have worked very hard and made some awesome progress so far, and we don't plan to stop. This year has also been a real learning experience, and through that I  have managed to come up with a bit of advice for anyone who plans to start out on something like this with their own group.

    

    Working as a team is extremely important in a setting like this, as you need to constantly communicate with your peers.You need to know what is being worked on, and need to collaborate on things so that they turn out the way the group wants. It is also important to be an active member of the team; you can't just slack off and ride along on everyone's coattails. Everyone needs to do their part for the game. Otherwise you will end up with angered people and a dysfunctional group. It is important to be working with people that you can trust, as well as people that you can count on to get their jobs done.  

    We bit off a lot more than we could chew this semester, and I will bet that you will make the same mistake; in an attempt to make an amazing game, we tried to incorporate too many things into the game at one time. Now that we are nearing the end we are finally getting it together, however throughout the year we were quite the unorganized group. If there's one piece of advice I could give, it would be to only tackle jobs that you can handle, and not to go overboard on the details. You will spend a lot more time on pointless things than you will actually developing the game. Once you get all of your important bits set up and working, then you can start adding extra effects like particles, game features, dialogue, etc. 

    I learned a good amount of things this semester; from technical coding things to artistic and musical design. Aside from the bigger topics above of course, you need to be aware of many different things. For one, it is very important to stick to your original ideas and not get ahead of yourself. You'll want to change things as you go, just try not to outdo yourself. It is also very important to make sure you are organized with your code and your setup; make sure everything is put together neatly so that when you do need to change something, it isn't too much of a hassle. 

    This class has been by far one of my favourites in all of my time here; I enjoyed every minute of it, whether I was spending hours fixing errors, or  I was composing some music for the game. I, along with some others will not me ceasing development of the game; we do actually plan on continuing to develop drop dead and other games in the future. Now that we know what we are doing and have a good team with the right skills and software, we can work together to make some awesome video games. The blog posts are done for now, but they may return; just not on a daily basis. That way I can still have some sort of showing my progress to the outside world. 

(Don't forget to check out my soundcloud as I will be posting some new music there in the near future. My keyboard is here and  I have the hardware to hook it up to my computer, so production will begin again very soon)

Day 74: IT WORKS. IT FINALLY WORKS.

Tonight and in class I have worked on the slopes and jumping for the game that have been broken for the longest time. I was finally able to make everything work, without any weird glitches. Take a look for yourself:

The player is finally able to go up and down slopes of varying angles (to some degree) and even hang off of steep slopes that the player can't normally walk upwards on. However, I can make it so that player is able to take slopes of much higher angles if I really want to in the future. I made many changes to my movement and jumping code throughout, most of which I can't even list at this point (I forgot most of them). Now that this is finally finished, I will be able to transfer it all into the main game, and finally get on with some more progress (That will be a task for next class). Aside from my success there, I do have a problem where occasionally the player can climb up walls, but I can fix it just by making a separate wall object instead of just using the floor as a wall.

Day 73: Jumping for Joy! ...wait

I finally remembered to put my own game into my Dropbox account! (Huzzah!) Finally I can work on getting the slopes integrated into the main game... although there is a slight problem; my jumping still is broken, and I cannot understand why. Currently when I try to jump, it just doesn't work at all... that's how much progress I have made so far. Previously it would cause the player to hover midair as long as the player was moving left or right. Once the player stopped, then the jump would continue. Through some attempts at fixing it, I have even made it so that the player can't move at all. Or other times, where the player can move, just as long as it is through the air while jumping or falling.  I have tried everything, from changing the way the player jumps, to changing how gravity works in the game. I've even tried only allowing gravity to have effect if certain conditions are met, which still isn't working. Here are a few examples of what  I'm trying to use to fix this:

Changing the way the player jumps:
- Changing the vspeed of the player to go in an upward direction and reducing it with gravity
- Using move_contact_solid (90,15) to move the player in an upward motion
- Attempting to change the y position of the player using y-=(n)

How gravity works and affects the player:
- Only allow gravity to have effect if the player is in the air/not in contact with anything else but the floor(using: if !place_meeting(x,y,par_Wall){gravity=1}else{gravity=0}
- Make gravity in a different way: move_contact_solid (270,15) ;
vspeed=15;

With gravity in effect on its own, my movement code doesn't work. I am trying to find a way to correct this but alas, nothing is working. Instead of using hspeed and vspeed, I am using x+=(n) and such to move around. They are essentially the same code, just slightly different in the way they work. Gravity and hspeed work fine together, but hspeed and slopes do not. However, slopes and x+=(n) work amazingly together, although x+=(n) and gravity do not. Of the three nice things, it would seem you can only pick two in this case. I think it is just a matter of getting a gravity setting in place, or something that will change gravity properly based on whether or not the player is colliding with the floor. Next class I will try my best to come up with a better system for this. Obviously the "if !place_meeting" idea isn't working too well, so I will have to come up with something else. I might end up playing with custom variables to detect when the player is in air and when they are on the ground, changing it based on if they hit the ground or hit the jump key. I am hopeful here, but I don't think it is going to be quite so simple.

Day 72: Many Things to Do

Today I worked on a few things. I started out by fixing an earlier mentioned, Ammo issue, where the ammo wasn't being subtracted properly. It turns out it was only for the pistol, and was an extremely easy fix. Just had to replace a number. From there, I helped Stephen to understand power-ups. To do this, we made a triple-shot power-up effect, that for a few seconds, shoots three bullets at a time, 20 degrees apart from each other. First we separated the shooting events into their own cases, using variables singleshot and tripleshot. Then, we just made it so that the single one starts at 1 at the beginning of the game, and the triple at zero, and when the power-up is contacted the opposite is true for a few seconds. All we need to figure out is how to make the powerup spawn randomly, which could be done easily with the random_range thing, as well as picking a random place for it to spawn. From there,  I worked a bit on some scenery.  I have fixed our old house sprite to fit with the platformer style, and  I plan to put it in the game tomorrow. I just need to align the room transferring object so that you can go in and out of the house properly. Tonight I might start transferring the movement code with slopes into this game, but I might be too busy - I ordered a digital keyboard recently and it is being delivered today. If I don't get the movement code done,  I'll at least save it for tomorrow's class. I'll at least have some music to edit tomorrow if nothing else.

Day 71: cONFUSION

So... please excuse the lateness for this post, as I forgot to make it on Thursday.

Also I have forgotten what  I did on Thursday. I am pretty sure I tried working on slopes, as I don't really have anything else that I could have worked on. Now although I cannot remember what I did then,  I can say I managed to do a fair bit of work on my own time. Over the  long weekend I was able to make some substantial progress on slopes; I finally got them to work properly! (In my own game, at least.) I am just having a problem with my jumping right now, but I think that wit ha bit of time I am able to fix it. I think I am just going to completely redo the movement for this game, taking the movement from my own. I don't have a copy of it here at school so I'll have to work on it later.For now however, I do have one issue I can fix. Currently my Ammo is not subtracting properly, which means the player is getting about 2 times more ammo than they are supposed to. [Next class] I will work on fixing that issue, and later on I will start moving my new movement code into here.