Devlog 2: Basic Movement:

Wizard Wars is a game that's entire gimmick revolves around movement. Moving your spells after you shoot them is the "main" thing, but it'd be a rather boring game if you couldn't move yourself as well in order to dodge the spells (although it still could be a rather enjoyable game. Nearly a tower defense. But I digress). 

Regardless of that, this week I implemented Movement mechanics, for both the player and the spells. As I don't have any sprites right now (I'll work on that later), the players currently look like red/blue circles, with the Spells looking like Orange and Light Blue circles. While the Players will have more complex sprites, the spells will likely only have simple animations of glowing and dimming, as well as a few particle effects.

So, movement. It was quite difficult and I had to remember a few things, as well as look up some documentation. Originally I had it work as a bunch of "If" statements, checking if certain keys were down. For example, it'd check if the W, S, A and D keys were down. Then, using that, it'd figure out which direction to go in. However, I forgot some code that would make it stop, so I had to implement it in after a test (effectively I just set the direction to 0 every frame, so it wouldn't go anywhere).

After that, I duplicated the player (and the script) in order to make a second player. That worked, and it was progressing smoothly. I made sure to add a "Speed" variable so I could alter how fast and slow the players would go. So then I got to work on a Spell. Nothing fancy, not even code to create one, just code to make it move. I came up with the plan that I'd link it with the script that moves the player, which would also have all the code for moving something far away. I don't know why I wanted to do that, it would've been much simpler to have independent scripts for all of them, as I would soon find out.

I deleted the script for the second player's movement. In English terms, I had made two different "ways" to move (scripts), but I thought the simplest way to move things would be to only have 1 "way" to move (a single script). Then I could tell the Spells "way" to move to see what the Players "way" to move was doing, so then it'd respond accordingly. I have no idea why I didn't just make seperate scripts, as that would've made life incredibly easy. But if I wanted that I wouldn't of become a Game Developer, would I?

Regardless, over a lot of trial and error, I refined the 2 player scripts into 1 script by converting the Keys into variables I could set for the players. This lets me alter which key something is using in the editor, rather then in the code. Now I could also add in a "Controls" section if I really wanted, but I probably won't. Wouldn't add much to the game, so yeah. This also meant I had to switch back to Unity's old Input system, as that's the best one for adding "variable" keys, which I have no idea why Unity ever switched the Input systems, the older one is way easier. 

Once the player script was done, I made a simple one for the Spell's movement, which would get how the spell figures out what direction it would move. Since this Devlog is getting a bit long I'll focus on the most annoying part of it: It would only go diagonal. Essentially I had it so that it'd figure out whether it was suppose to go up or down, then figure out if it was supposed to go right or left. However, I'd simplified it to then figure out where it was going based on those options, there was no neutral option. When I attempted to implement it, it would just make it stop as most of the time you wouldn't be pressing a key. I didn't like that, since I wanted spells to always be moving, so after some trial and error I learnt about Switch statements (which are called "matches" in Python) which would essentially look at a variable, check what it's value is against several "Case" statements, and then do whatever it says.

After that, it was pretty simple. I just connected the code, and yeah. There is a glitch with the current build that the screen isn't big enough to fit everything in, but by the time this is read it'll likely be fixed... hopefully. On the topic of fixing I should really fix "A Colder Case..." Eh, I'll solve that later. Until next time!