One week before first playable version

One week before we need a playable version of our core mechanics for the class the try, but I have set the deadline to this Thursday instead. That way we will have another half week to fix everything we will not get done until Thursday, (wow, that sounds really confusing, hopefully someone will understand me, maybe).

We had Scrum-meeting today. Scrum is a work method where EVERYTHING that is to be done is written down, like milestones, and each week every team member pick one or more things to work on. We estimate how long we think we will work with each part and set a risk, how high is the risk that we will not be able to finish that part before next week (low, medium or high).
Anyway, the meeting went smooth and everyone got their next quests.

I also did a couple of hours of coding. Started working on our guards sound detection system. When someone makes a sound, the sounds position, volume and cause (player or guard) is stored in a vector. It is also checked if any guard is close enough to hear it if it was the player creating the sound. If they are, a waypoint is to be set for them to the origin of the sound. This check is only made when a new sound is first created, so the reason to save them in a vector is because we will draw ripples from the origin of the sound if the player is close enough to hear them. So not only will sounds have an audible effect but a visual too.

I only had time for about 2 hours of coding today, so didn’t finish it yet. But I got the concept of how it could work and I can’t really see any bigger problem that a couple of minutes thinking can’t fix 🙂

 

Guards and their different states

What will the guards be doing?
The guards will be idling, patrolling, investigating, searching, chasing and shooting.

Shooting they will be doing if the player are in their line-of-sight for too long.
They are chasing when they have seen the player but he/she is no longer in their line-of-sight.
They are searching if they know that the player is around, but not where.
They are investigating if they hear a sound but do not know about the player.
Patrolling and idling will be their standard behavior when they are not aware of the player.

Each guard will have his/her own GuardStateManager. It will function just as the StateManager that handles the game-states. The only difference is that it holds GuardState-pointers instead of State-pointers.

• Patrol: A guard on patrol will walk from waypoint to waypoint until he/she detects the player, either by sound, sight or alarm. Each time it comes to a waypoint he/she will stand there for a while, looking around.
• Idle: An idle guard stands his ground until a player’s action changes his/her behavior.
• Chase: If the guard has just seen the player but he/she has moved out of the line-of-sight the guard will move to the last known position as if it was a waypoint there. If there is no more sign of the player when he/she reaches the waypoint the guard will enter its Search-mode.
• Search: A waypoint will be set somewhere close to the guards, which he/she then move toward, behaving as in Patrol-mode but with no fixed waypoints to loop through.
• Investigate: If the guard hears a sound and is not in Chase-mode he/she will investigate it. A waypoint will be set on the sounds origin and search for a while close to it. If the guard does not hear or see anything more he/she will go back to what it did before.
• Shooting: If the player is in line-of-sight for too long (about one second) the guard will fire his/her weapon and the game is over.

The picture shows how the guards different states changes between each other.