Artifact of the week: Implementing Morker

Hello there!

Last week we made a prototype of the morker that was able to shoot bullets towards the player and move to each side to make it harder to hit it.

So this week our task was to implement it in the main project that we have started to get together after some struggles with github.  Even though we already knew what we wanted the morker to do and how we could do it in the prototype, it was another thing to do in the real project. So we started with the basics and took the code from our melee enemy, the warrior. They both have three states; passive, aggro and attacking. So we only had to change what the states themselves consisted of and when they were switched in between each other.

The passive/idle state was pretty much the same. The condition to go into the aggro state is not done yet. It is supposed to get into aggro state when it is hit, but because we do not have collision between projectiles and units yet in this project it is still the same condition as the warrior(aggro range). So last is the attacking, that is where they differ greatly since one is melee and one is ranged. So what we did was to take the same function to make the warrior move towards the player, but we placed it on the projectile we created instead and did not update it. If  we did that it would have been a homing missile what was not exactly what we were going for.

bandicam 2014-03-06 23-32-38-913

Next thing was to make the morker to zig zag to not be so easy to hit. The reason we  want it to  zig zag is so that it will be more of a threat when it is being aggroed. It can only be aggroed by taking damage so if you are able to manage your shots you will not have to worry about them. So we used the if statements that i wrote about in the last post. My co-programmer Jokke figured out how we would be able to get the morkers to move in different directions depending on where the player was. It was as usually not a ground breaking way to do things but it did work nicely, we just used some if statements to check whether the player was to the left or right to the enemy and at the same time if it was below or above him.

bandicam 2014-03-06 23-26-28-632

So that is it for this time, take care and i’ll see you in class =)

One thought on “Artifact of the week: Implementing Morker”

  1. I’m not sure what “the Morker” is from reading this post, I can understand that he is an enemy, and you describe his behaviour (or intended behaviour) pretty well, but I have no idea of how he look, nor do I know how his movement patterns will look in-game. Will he maintain distance from the player (I think it was a ranged unit?) or will it keep closing in while zig-zagging towards the player, despite being ranged?

    You mentioned you had a prototype for the Morker, why didn’t you use screenshots or movies of that prototype? A prototype is great for showing how it is intended to work. As far as I know, you’re not supposed to upload images of the code alone. You need at least one image that is not a screenshot of the code.

    Code screenshots aren’t to useful for the outsider reading it, we don’t know what some of the member variables are for example, or what the functions do outside the code we see. What is TextureMan? And what does the Get function do in it? What significance does it’s argument have? I can guess that TextureMan is a manager, and that the Get function get a preloaded texture, but it is not readily apparent for an outsider. A non-programmer would not understand anything in the screenshots, it’s better to use other screenshots or images.

    You mention you had troubles with Github, I’d love to know more about the problems you faced, and how you resolved them, many of us have some issues with Github.

    That aside, great post, not boring, keep a red thread so-to-speak, and you describe your intentions well. Just a few misspellings that could’ve been avoided with a double-check.

Leave a comment