SoundRipples, Guard Patrolling and Light-prototype

I have been working on two things today. I continued with our guard’s detection of sounds around them and got our PatrolState working.

I’m having a SoundRippleManager to hold a vector of SoundRipples, which is basically an object with position, volume and time alive. The SoundRipple will stay alive for about 1 second and during this time it will draw an expanding circle from its origin to represent our visual respond to the sound.

When a new SoundRipple is created it checks all the guards’ positions to see if anyone is within a certain range, depending on its volume. Everyone that is within hearing range will set a waypoint there to check it out. I did it like this just to see if I could get it working properly, and I think it does. But what I will do, when I have made it, is to change the state from Patrol to Investigate, instead of just adding a waypoint to the sounds origin.

The PatrolState is working, kind of like I want it for the start of our alpha stage. Only big thing to add is to implement the line-of-sight so it can detect the player even if he/she doesn’t make any sound.

Our light-prototype is pretty awesome looking now, and I really want to get it implemented to see how it will look with all the sprites. Most of the strange bugs are fixed now.

I can only find one unfixed that occurs if the light gets too close to the wall. I have to remember to ask Robin take a look at it on a later date, it is good enough for now. We have more important things to implement first, like collisions 🙂

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.

Sprites, Animations and the Manager for them

So, what have I been doing since last update?

Well, I have been pretty sick for a while now so have not had the strength to code much but I have been working on our Sprite Manager and Animated Sprite. It think I got it working as I want J

The Sprite Manager loads and stores Textures. It also creates pointers to Sprites and Animated Sprites which other managers need. When an object asks for a Sprite or Animated Sprite the Sprite Manager looks for it in the map that holds the textures. If it can’t find it, it loads and saves a pointer for it otherwise it uses the “old” texture instead. It is kind of waste of memory to load the same texture twice.

The Animated Sprite class has a vector of Frame’s that holds x, y, width, height and duration values for frames of an animation. So each frame holds coordinates for a rectangle of the Texture that is associated with the Sprite and the duration it should be shown before switching to the next.

Up next: Create some guards, load their sprites, position and waypoints from a text-file and make them patrol.

Level Editor in C#

Yet another long day.

I have been working on a level editor in C# for our game ”Escape”.

Why a level editor?
Because creating a level would be pretty hard without it. Because we will not use tiles, the level designer would have to manually type coordinates for each item on the map. Tables, chairs, guards, waypoints, exit, entrance, keys, etc. The editor will allow the designer to build the level by choosing an Entity (guard, furniture, etc.) and rotate and place them wherever he/she wants. It is then saved to a text-file that the game can read.

So far one can place Tables, Chairs, Lamps, Wall corners, Guards and their respective patrol Waypoints, and save it all to a couple of text-files. So the rest of the entities are left to do, and maybe some cleaning up. It is chaos in the code at the moment. Instead of using Structs to hold coordinates and such, I have been using at least two different ArrayLists, one for the X-coordinate and one for the Y-coordinate. But the cleanup it something I will do later, when I got the time, because it is working as it is (most of the time at least).

Tomorrow we will have our first real checkup to see what people have been doing the last week. I don’t think we have been gathered all together since Monday, someone has always been unable to get to school for different reasons. Hopefully everyone will have made at least some progress.

Next game started – Concept “Escape”

After a couple of weeks silent I’m now back for more regular updates.

In our new course Game Development – Introduction (I think it is called) we are to choose another groups concept and develop it to a working game. It is the same group as in Game Design – Introduction except that we got another member, a graphic artist, and we chose to take the concept “Escape”.

You are an agent and have to escape a building without getting caught.
It was one of very few concepts that were even remotely interesting. Most games, according to their pitches, sounded really strange and/or boring. I voted for Escape for my group because it sounded fun and had some interesting programming challenges.

What I’m working with at the moment is a Level-editor. It has been great fun, learning C# (C-sharp) and Windows Application Form. It was slow at start but I think I got some grip on it now. C# is pretty similar to C++, but still not. It is like a blend of C++ and Java, most of its syntax is good old C++, but everything is done in classes, like Java.

Another challenge I have been looking forward to is our lighting effects. Our game is to be a stealthy game so good lighting effects are high priority. We don’t want the player to be able to see through walls, doors and round corners. So I have been looking on different ways to make that happen.

First thing I found was something I think is called Ray-casting. Basically it is drawing lines straight out from the player, all around him/her, until they hit a wall. Even if that sounds good, it is not quite what we want.

Another way to do it is looking for all the corners around the player. Then draw triangles with one corner always at the player, and the others either at obstacle-corners or, at the wall behind the corner, like the picture.

The last thing I think can be a challenge is the AI. It sounds like a good thing to use different states for them. The states could be:

• Guard-patrol: The guard goes from waypoint to waypoint.
• Guard-chase: When the guards sees the player he goes from patrolling into a chase mode where he tries to shoot the player if he can, otherwise moves toward the he/she’s last known position.
• Guard-search: If the guard gets the where he last saw the player he will enter search mode. In this state he will pick a point within a certain range and go there, looking for the player. Over time it will start search in a wider and wider area, and at last, when he has search most of the level he will reset to Patrol mode.

As search algorithm both for finding a path to the next waypoint and for the search mode we will most likely use A* (A-star). It sound like it is the most popular choice for 2D-searches.

My goal for this week is to get the Level-editor good enough to work, read in the level from a couple of text-files the editor generates and get the player able to move detect collision with walls. Those goals were sat before we knew we could use a Level-editor, so my hope for getting everything done in time is not great, but I will do my best.