Zombie Game

Wasn't too long ago that I posted here but a lot of visual/art updates since then so here it is again:

Slight Change to Aiming Bar Mechanics

• Got rid of "Aim" & "Shoot" button
• Tap on the quadrant of the screen you are on to fire
• Tap on a quadrant of the screen you are not on to cancel fire and move

Think this is a great help as your eyes stay closer to your target so you can catch the animation and also gets rid of the tiny tap target (where if you miss it you move across the screen).

Planning on trying to find a better look for the bar. Right now am thinking to make it smaller, outline (maybe in white), and possible changing the arrow to crosshairs. I kind of like the green, even though doesn't make logical sense feels it matches the theme & art.

Also, I need to stop procrastinating on redoing the movement animations! That is the main reason I haven't posted links to any demos or tests—too embarrassed of that movement and try to capture screenshots without him moving, ha.

Note: Will probably reduce the size of the headshot bar—either I'm getting good or it is too big.

Events for New Targeting System

I wanted to post again showing some of the events for my fellow Construct developers. I apologize as this post may be a bit unorganized, images won't cover all the events pertaining to this topic, and a lot of basic boring events in the images. But I decided to post anyway to throw some stuff out there to anyone interested and feel free to ask me questions if you want to learn more about it. Also, I hope to clean up and organize all of this once it is more finalized, so sometimes explaining it to others can really help clarify it for myself.

So lets get to it:

Pointer Movement

I'll start with how the pointer moves back and forth across the bar as this is probably the most interesting part to other developers, even though it is really a simple lerp(). I'll start with the screenshot of the events:

• So first off it is contained in a deactivated group so it will only run when desired.
• Arrow has two instance variables: Speed and Position
• Every tick Arrow's position is set to lerp() where 0 is left border box of the bar and 1 is the right border box.
• The Instance Variable 'Speed' is added to Instance Variable 'Progress' every tick (with the dt to make framerate independent)
• Everytime arrow reaches either end (0 or 1) the speed slows down, this is to give the bonus of making it easier the longer you 'aim', and the direction is reversed. Could have just multiplied by -1 but didn't want to risk it running twice and cancelling out so used absolute value. To make positive take the absolute value, to make negative take the absolute value and times by -1 Example: abs(-10)*-1 is still -10

The other events below I won't really speak about as most are straightforward, setting position and visibility, etc. I use a lot of functions so it may be impossible to follow everything.

I will highlight one thing: setting the width of bar1, bar2, and bar 3. These respectively are for head shot, body shot, limb shot/grazing shot. The size they are based on depend on the distance of the enemy which is passed as a parameter to the function. I plan on tweaking the formula later when balancing testing but is basically subtracting the distance and dividing by numbers to found when testing.

Feel free to ask any questions as I know I didn't cover everything. Hope a few enjoy and find it useful

If you aren't using a movement behavior I recommend using lerp() — no plugins required.

Create instance variables for StartingX, FinishingX, Progress, & Speed.

Group(initially disabled)

-Every Tick

--Set Position to lerp(StartingX, FinishingX, Progress)

--Add Speed to Progress

-If Progress > 1 Disabled Group

Then when its time to move you set the starting and finishing variables, set progress to 0 and enable the group. Presto!

If the only effect they have is visual you can make them invisible. Either have an event that selects all and makes invisible (i.e. on tab key pressed toggle visibility) or put them all on one layer and have the whole layer invisible.

If it isn't just visible you could have an event that destroys them all every tick. Put that in a group and can toggle the group active/deactivated

Are you doing the art for this? Love the pixel art style

I want to make a suggestion to help but really don't understand the

...i want to make smooth, jerky movement - like jumping frog in my game

You could use lerp() but I wouldn't use a static third variable—that smoothing wouldn't make me think of a frog jumping. I usually use lerp with instance variables so it looks like lerp(starting, finishing, progress) and put it in a deactivated group. Set progress to 0, activate the group where every tick add speed (another variable) to progress and when progress >= 1 deactivate the group.

Of course you can do this a bunch of different ways. If it is a jumping look you are going for I made these blobs with custom movement and timers, and of course animations:

—

How do you disable user input?

How would it look on an Event Sheet?

I still need to figure out how to avoid collisions with another object. Such as a falling rock and I go to hit jump up, the rock needs to then be able to pass under the player while the player jumps.

You could put the controls in a group and deactivate the group. I usually turn the "Default Controls" to No and event my own controls so I have more control over it. I thought there was an event to set the Default Controls to no but can't find it. But however you have the controls setup you disable it, could be with a variable also. (If left arrow down and ready = true then simulate left. If doing that way just change the boolean ready to no)

If you aren't already using a movement type I would use lerp()

If you aren't familiar with lerp() it is actually pretty simple. lerp(position1, position2, progress) -> progress should be between 0 and 1 where 0 = position 1 and 1 = position 2.

So I would have an instance variable of progress and speed. Then Left and Right I use below are the farthest left you want the player to go and the farthest right you want the player to go.

Events would be:

Every tick -> Add Speed to Progress; set position to lerp(Left, Right, progress)

--Progress <= 0 then progress = 0

--Progress >= 1 then progress = 1

--Speed > min speed then reduce speed by ?

Every button press

--Speed < max speed then increase speed by ?

Your speed is going to be very small because a speed of 1 would move from left to right side of screen in one tick. Even a speed of 0.1 is too high. Maybe have max speed be 0.02 and min speed be -0.02; increase on button press 0.001 and decrease every tick 0.0001. ...those are just educated guesses though from math in my head, so may be way off.

If you are confused could throw together a capx but probably not anytime to soon... hope this helps

What about this:

Disable user input (however you have it setup)

Increase movement speed

Play jump animation

Simulate input in desired direction

--

Return movement speed to normal

animation to default

enable user input

Very nice thread - I enjoyed reading through this from start to last post Good luck in your development I like where this is going!

Thank you! I hope to have some time soon to post some more and work on it further.

Thank you so much. This happens a lot. Do you know why?

When you edit the image in certain ways the origin remains in the same spot, for example if you paste a small image and click the auto resize the origin will remain in the center of the originally sized canvas.

Personally, I have found it is best practice to check where the origin is after editing an image every time.