Sixth Artifact: Level-changing

I have been working hard on bug fixing everything this week. A lot of progress has been made. For example, the guards no longer plays lighthouse when the player is nearby, was a minus instead of a plus when calculating the distance that was the reason for that. Anyway, let’s get to this week’s artifact.

So, we are going to have four levels in our game, and we do not want to load all four at the same time. I have not coded this part yet, but I have been thinking about it a lot the last couple of days.

We need a way to change from one level to another, but how are we going to do that? I got two ideas: one using if/else and the other using different states.

First, the idea about using different states. The way it is supposed to work is that depending on which level the player is on, different “level states” are loaded. So, a lot of code had to be copied from the game state into the different level states. This was the first way I came up with. At first it sounded like a good way to do it, but the more I think about it, the more I think that another way is better. Not so good on copying code, because if I have to change it later, I have to change in everyone.

The other way to do it would be to have a variable that says which level to load. Then in the Enter function in GameState, we look which level to load and set the path to the folder where the level information lies.

As I said, the more I think about it, the more I think the second way is the better. What I need to do to make it work is putting everything common to all levels in one folder. That would be all pictures, except the level background (which is specific for each level), animation text files, sounds, music and probably something more I have forgotten now.

Each level has its own folder which contains the information about walls, furniture’s, guards, starting position, etc.

Then, when the player has finished the level, we change the variable that indicates which level to load and manually call Exit() and then Enter(). So, instead of creating a new function where every wall, furniture and guard is deleted and then re-initialized for the new level, we use the two functions we already have for the state manager and seem to work as intended anyway.

The picture is a room on our second level.

Fifth Artifact (maybe not really an Artifact): Get it ready for beta presentation

The last week I have gone through the code, implementing and bug fixing the last things that needs to be done before we are ready for our beta presentation.

So, what needed to be done the last week? Well, a lot of things. The weeks between alpha and beta we have been working hard on getting things done. Pathfinding, furnitures, collision with things, guards AI, etc.

We had a play testing session the last Monday, and early Sunday we did not have a working game… Most things were not implemented. We did not have working furniture’s, guard pathfinding, lose or win condition, sound or music, doors, the right level (we still had the alpha map).

So, because I knew I would not have the time to make all of those things work, I had to prioritize what to do first.

I started out working on the guards AI, they did not behave as I wanted them to. They were seeing and walking through walls, some times. Some of them are standing in front, or even inside walls (see picture), I think that there is something wrong with their spawn positions and/or their waypoints for patrol.
I fixed most of the problems, but some rather huge are still there. They are kind of hard to pinpoint because they happen so rarely.

I really dislike pathfinding at the moment. I could not find out what was wrong with my A star code, it did not prioritize nodes closer to the goal, but expanded equally in all directions. This made the pathfinding very inefficient and the game was lagging really badly during the play testing. But yesterday, when I sat with it, I realized that I had made the cost to move between squares 10, but the distance to the goal only weigh 1 for each square. After I had fixed this small miss step the code is about infinitely faster if it has to find a path to a target somewhat far away. Before it could freeze for a couple of seconds, but now, it is not even noticeable. I am so happy about that.

Monday morning I was hoping for some help with implanting the furniture’s, doors and those things that were ready for implementation. But because I had not worked with the manager’s for those, it till most of the morning. I got, kind of, done about 10 minutes before the play testing, but they had no collision detection yet. That part I did not have time for.

The problem with the sound and music was that I had moved them from their original folder to another, but forgot to change the path. So that was fixed really fast. I am glad that we didn’t get the footstep sound to work before the play test, because they are REALLY annoying to listen to. It sounded a bit like sitting and hitting two coconuts against each other. So, either we have to find another sound, or just scrap the idea of hearing the characters footsteps while running.

Tomorrow is Beta presentation, and I think I got everything that is essential for it done.

This week’s artifact: Sprite Manager and a quick look at Animated Sprites

Even though it was long time ago they were made (like 5 weeks), I think it is time to talk some about them.

Both the guards and the player have a lot of different animations.
For example, the player has:

• Sneak
• Run
• Idle
• Dying
• Attack
• Strafing
• Walking

And the guards have:

• Draw weapon
• Walk
• Run
• Idle
• Smoke
• Falling
• Rising
• Shooting

And instead of asking the Sprite Manager for a new animation each time it needs to change it, each Animated Sprite holds pointers to each animation instead. So, all that is needed to change from one animation to any other is to tell the Animated Sprite which to switch to and it will search through all its animations and change the current animation to the new one.

 

The Sprite Manager is managing the textures, so maybe I should have named it Texture Manager instead. I think that would have been a more accurate description of what its main purpose does.

Its primary function is to make sure that the same texture is not loaded twice. When it is asked for an animation or sprite, it looks through all the previously loaded textures. If it finds another texture loaded from the same image-file, it will return a pointer to that texture. If it is not found, it will load the new texture and return a pointer to that new texture.

When the game changes state, it will release all the memory of the textures, so that it doesn’t hold them when they are not needed.

 

When an entity asks for an Animated Sprite, the Sprite Manager needs to know which text-file to look for. In this text-tile, all the necessary data for all that entities animations are stored. Like which picture to load, each frames duration, at which coordinates each frame starts, and its width and height.

The text is which image it should load. The first number is that frames duration. Second and third are x- and y-coordinate of the upper left of that frame. Fourth and fifth are width and height for that frame.

It would look something like this in the text file:

Guard1Running.png
0.1 0 0 96 96
0.1 96 0 96 96
0.1 192 0 96 96
0.1 288 0 96 96

Guard1Shooting.png
0.2 0 0 96 96
0.2 96 0 96 96
0.2 192 0 96 96
0.2 288 0 96 96

Guard1Searching.png
0.2 0 0 96 96
0.2 96 0 96 96
0.2 192 0 96 96
0.2 288 0 96 96

The Sprite Manager is then using this information to create an Animated Sprite. When it has come to the end of the text file it will return a pointer to the Animated Sprite it just created.

By doing it this way it is easy to add new animations to, for example, the guards. All that is needed is a new sprite sheet with the frames, and then add the information for that animation at the end of the text file. Then, that guard just have to call the function ChangeAnimation(std::string animationName), that is part of Animated Sprite, to start using the new animation.

Third Artifact: Pathfinding and Grid building

This week I will talk a bit about our pathfinding. (Warning: Confusing)

There are a couple of different pathfinding algorithms out there, on the internet. There are Breath-first, Best-first, Dijkstra, A*(A-star), etc. Almost everyone, on different forums, suggest A* as pathfinding algorithm for most games. It is reasonable fast in most instances, even though some of the others were quicker in some scenarios.
A*, like most other algorithms, needs a tile based system to search through.
Each Tile, or Cell, is given three values: F, G and H.

• G is the cost to move from the starting Cell to this cell.
• H is the guessed cost to move from this Cell to the goal, as if there was no collision in between.
• F is the sum of G and H. (G + H), the approximated cost to move from start to finish through that cell.

Each cell also holds a pointer that points to its “parent”, which is the cell that put the active cell on the open list.

It uses three lists to store cells in: Open, Closed and Final.

• In Closed all the checked cells are stored, so we don’t check the same cell more than once.
• In Open all the cells still to check are stored.
• In Final we store the final path, when we have found our goal. We get the path by backtracking from the goal and go through all the “parent” cells until we are at the first cell.

Each iteration of the algorithm takes the cell with the lowest F-value in the Open list, and puts it on the Closed list. Then it checks all the surrounding cells that is not already on the Closed list and gives them values. It one of the cells is already on the Open list, it checks if the new F-value is smaller than the last. If it is, it changes the parent of that cell so it points to the new, cheaper, parent.

When the goal cell is finally found in the Open list, we backtrack from there. Going from parent to parent, storing each cell and when we are back at the start cell we have the shortest path.

The picture shows an example of A*. The Green tile is Start, Red is Goal, Gray are walls, Blue is on Closed list, Green on Open list and the yellow line shows the path we got at the end.

 

Unlike the other Escape-concept groups, we chose not to have tile based. The reason for this is that we felt that tiles are too limiting when it comes to placement of walls and furniture’s. We wished to have more freedom, to rotate and place assets “however” we wanted, to give each room a unique feel.

Because of this I had to simulate a grid to use A*, otherwise, each pixel had to represent the tiles, and that would be too many squares to search through. The grid is stored in:

• std::vector<std::vector<bool>>

Which is vectors in vector. The outer vector is the tiles Y-position and the inner its X-position.

Instead I divided the map into equal sized squares and checked each square for collision. If collision was detected I put its bool-value to false, otherwise true.

Then, to see if the grid worked I drew the grid on top of the level ingame, and each walkable tile was colored red and the unwalkable teal.

As the picture shows, it looks like it is working.

I hope I made myself clear, but I’m afraid that would be really wishful thinking…

Second Artifact – Level Editor (kind of)

 

Another week, another Artifact. This time it will not be from the game itself, but a tool to make it easier to create the level.

 

So, I have been working on a Level Editor for our game, With Intent. The reason for having it is so that it will be easier and faster to build the level with all the walls, furniture’s, doors, guards and their waypoints, start- and end-positions. Without an editor we would probably have to input all those coordinates, degrees, etc., manually, in a text file.

 

I chose to create the editor in C# as a Window Application Form. It was an easy transition from C++ to C#, it took a couple of hours to get the hang of, but after that I have had no bigger issues with it. It has been fun to learn a “new” language, even if it is like a blend of C++ and Java, two languages I have worked a bit in.

 

All positions, numbers and degrees are saved in a lot of different Lists<>. Those lists work a lot like Vector<> from C++, except that it seems like you have to “new” them to use them, at least I couldn’t find any way to work around that. And now that I’m writing this I’m realizing that I have not “deleted” a single one. I really hope that it is done by automatic in C#, like in Java, and not like C++. Otherwise it would be kind of embarrassing to forget something like that…

 

Robin found out what was up with our bugged walls, those that could be seen through if the player got to close to them. It had to do with X being much larger then Y, or vice versa. So I did so the editor, when it saves to the files, “cut” the walls in smaller squares then very long rectangles. I thought this part wouldn’t be that hard but I had a hard time concentrating on the task so it took more than the three hours I had predicted. I’m up to six hours now and is still counting.

 

The first thing to do after the editor have been loaded is to load an image. This image will be the mold to see where everything should be. The next thing to choose is what to place, walls, guards etc. Some things, like the guards and tables, will also need a degree to say in which direction it will be facing when it is created.

 

When the Save button is pressed it will save everything in text files, that can then be read by the game to create the objects in game. The picture shows a small part of the code that saves all Lists in text files.

Blog-post nr.1 5SD033: Game Development – Introduction

For soon four weeks, I and my group, have been developing a game we call With Intent (working title) which originates from the idea of Escape, which was a concept created by another group, about 3 month ago.

Each week I will pick an Artifact (piece of the game) and try to explain why we did as we did, how it went and if I would do it any other way next time.

……

The Artifact I have chosen to write about this week is Guards.
So, what is a guard? And how will they work?

The guard is the standard enemy (only enemy type) in With Intent. They will, among other things, be patrolling the level by following a fixed route. As long as the player is not seen or heard by any of them they will continue patrolling until the end of days. But if he/she is spotted they will try to shoot. If the player gets out of their line of sight before he/she is killed, the guards will start searching and there will no longer be any pattern to their movement. In this stage the game just became a lot harder to complete.

The guards will have different tasks they will do.
They will have one of three starting tasks:

• Patrol: They will go from waypoint to waypoint. At each waypoint they will take a short break to look around before heading for the next.
• Idle: They stand at one spot looking around. They might appear on crossroads or in rooms.
• Sleeping: Standing or sitting with their eyes closed. Will only be disturbed by sounds or contact.

And four tasks when disturbed:

• Investigate: If they heard you out of their field of view they will investigate the sound. If they get to where the sound was made they will look around for a short while and if the player is not seen, they will return to what they did before.
• Search: If they know of the player but have not seen him/her for a while they will start searching. Going from room to room, looking around. They will start searching in the rooms close to where they were when they last saw the player, and then increase their search area. If they are searching, they will not stop searching unless they find the player.
• Shoot: If the player stands in their field of view for more than about one second they will start shooting, and that is pretty bad.
• Chase: If they lose the player from sight the guards will start chasing. They will run to the last known location, either by sight or sound. If they can’t see or hear the player when they reach that place, they will start searching.

We want the game to be a stealth game where confrontation is very bad. If they shoot at the player, it will most likely be game over. To avoid that, there will be three main ways for the player to know if a guard is nearby.

• Each of guard, except sleeping ones, will carry a flashlight, pointing in the direction they are looking (not implemented yet).
• The ripples from the sound they make when they are walking or sleeping.
• Their actual body is within the player’s field of view, this will be the only way to detect sleeping guards, unless they are snoring.