Work continues on our final assignment for Game Programming I.
10/1: 16:00 – 21:00
Went over how my partner wrote the Room manager. He took inspiration from the Sprite Manager and made use of enums (he will add documentation eg comments to his code).
Since in our game, walls, doors, and ground tiles do not need an update function (they have no “behaviour,” just information, relationships, sprites and colliders), my partner decided they need not be entities. We termed these “background objects.”
If an object has a sprite and an update, but no collider, we term this as ‘gui element’.
Our entities will only include objects that NEED TO HAVE a sprite, collider, and an update function (eg items, enemies, and player).
We need to COMMENT the wonderful work my partner did on Room Manager and Camera so that it’s clear it was his personal effort!
Solution for sword: my partner’s found a solution inspired by GameProgrammingPatterns.com. Again this NEEDS TO BE COMMENTED IN.
Since we do not want the player to be able to move or perform attacks during an attack, we are going to have a “finite state manager” for the player. Around the player’s update function, we will have a switch. If the player is in an attacking state or taking damage state, the player will not be able to attack.
The player will have a sword collider, and if the update function sees that the player is in an attacking state, the code will check for collision between the sword collider and enemies.
The sprite of Link attacking with a sword will immediately be drawn instead of the sprite of Link moving if the player clicks the attack button.
This kind of finite state manager is extremely useful for jumping, double jumps, entering doors, enemy ai, etc. We will use this to create a Get Item state as well, so the player cannot take damage, move, or perform attacks while picking up an item.
my partner removed diagonal movement at least temporarily because it created problems with collision, since player’s SetPosition() takes in integers, and diagonal movement results in decimal numbers. We won’t prioritize diagonal movement until we get more important things finished.
To do:
-
I will do sound and probably hud (written in GameState after we draw all the entities). GUI probably doesn’t need an update function, since the variables it will be looking at (eg heart counter, coin counter) as stored in the player class, which uses the update function.
-
commenting on Room mng and on Sword collision! w link!
We got the sound manager working (forgot to initialize it, d’oh!).
We also worked on making an enemy killable by the player (collision between sword and enemy, taking scaling into account). We had a problem with this due to sprite manipulations for the attack animation, which we wanted to look natural. This resulted in a variance in sword collider coordinates when it came to upscaling. We addressed this by changing the collider in Player.cpp: Using coordinates for the centre of the Link sprite and the centre of the sword sprite, for both x and y axes, before scaling up (x5).
