WASD or arrow keys to move. Click to slash, which can either be used as a party to break the shield and cannons, or it can also be used to finish the boss when both arms are gone.
edit: forgot the link
This is really cool! I can definitely tell there was a lot of work put into this so far! However, there are a few things I think could help:
Firstly, why does the project start with the player pressing space? I would think the green flag would make more sense, as that's how more or less every single project on Snap! starts. By using space, it also makes it pretty buggy, as the player can hit space again while the game is already running, and cause the boss to do weird stuff during the intro.
Secondly, clicking isn't the greatest control, so I would suggest using the space bar or clicking as an attack, so the player can choose which one they prefer.
Thirdly, using the when [space V]key pressed block almost always isn't the way to go. Instead, I suggest using something along the lines of
when green flag clicked
forever {
if<key [space V] pressed?>{
do stuff
}
}
Thanks for the feedback! The green flag thing makes sense. I personally prefer to have most of my controls on the keyboard if possible, which is why I chose space.
As for the clicking, I did that so you could choose which direction you wanted to slash in. Although now that I think about it, you could do the exact same thing with the space bar.
Although I'm curious, what's different between (when space key pressed) and if (key space pressed?)?
The big one is that it can be triggered even when the project isn't running. For example, if you used those blocks as movement, then the player could move around even when the project isn't running, which wouldn't make much sense. On top of that, if you were to start holding, it would do one iteration of the attached script, wait a moment, and then start repeatedly doing so. (Basically functioning the same way as when you hold down a key on your computer while typing.)
Thanks!
After the functional changes, though, I have a couple ideas on how you could further expand on the game.
First, giving the boss some more attacks and some attack variety could help a lot. While the attack you have right now is great, as it functions well and looks nice, it's ultimately fairly simple. By having many attacks that the boss can choose from, it can keep the game a lot more tense, not knowing what the boss is going to do next. An example could be an attack where the boss shoots projectiles at the edges of the screen, and they bounce off the walls, making them both difficult to deflect and to dodge.
Another thing is that the player can just spam the attack button, resulting in the gameplay degrading into "how fast can you click" rather than trying to actually fight the boss. By adding a cooldown, if even a short one, on how fast the player can click, it would give the boss much more of a chance to win, and make it stronger. However, more importantly, it would force the player to be strategic with their attacks and time their slashes carefully to deflect the bullets, rather than just click so fast that they basically gain a forcefield.
Another code-level thing is that you can use anchoring to significantly reduce the complexity of the boss's code. In case you don't already know, anchoring is where you tell a sprite to "anchor" to another sprite. What this does is make it so that when the anchor of a sprite moves, that sprite moves with it. And the best part about this is that the other sprite that is being anchored can still freely rotate, and even move on it's own, and do whatever it wants. To anchor a sprite to another sprite, you need to use the dropdown menu on the set [ V] to ( block, under the "my" part of it, to get set [my anchor V] to ( Lastly, after doing so, you need to run this script on the sprite you want to get anchored (the one that's being dragged around):
set [my anchor V] to (object [anchor V]), with anchor being replaced with the anchor. (the one that drags the anchored sprite around.) On top of that, to undo this, returning a sprite to normal, just run set [my anchor V] to (, leaving the input blank.
Using anchoring, I definitely think the code would be much simpler, as right now, you have all of the parts of the boss repeatedly positioning to each other, and sometimes moving after to get a desired offset. With anchoring, none of that is necessary; just make sure everything is positioned correctly relative to one another, set the anchors, and no more positioning is required.
why? I would definitely use the hat block, because it is much faster - the forever if requires snap to constantly be checking whether the key is pressed or not.
Does the hat block not also do that? And in my projects, I'm always going to have some sort of main game loop, so the forever loop part isn't really a problem. On top of that, it might be faster, but it seems like trying to design a game loop with the player controls not actually being in the game loop would just make the project slower than just having it in the loop to begin with.
Also, when I suggested that, that's not really what I'd do, it's just to say "put it in a forever loop". Projects that have multiple copies of that script, all under separate hat blocks doing their own thing still send shivers down my spine of how slow and inefficient that really is.
And if I were to make one with only one input, I'd just do this:
when green flag clicked
forever{
wait until <key [space V] pressed?>
do stuff
}
no, when a key is pressed it sends a signal to the computer, rather than snap constantly checking if it receives a signal.
TYSM! I had no idea this was even a thing. This would have saved me so much time lol
I think you should add a Shield for the player if you press a button. that Would be cool!