Level Editor

Now when all of the features of our game is finally implemented we've been working hard on our levels. Our game is played on four floors where the first, top floor is the tutorial. After the tutorial the player is going down until he is on the first floor where the game end and he wins. The levels are loaded in from text files and those have become extremely hard to create since we have so much that needs to be loaded. Therefore I've been working on an editor to make level design much easier.

The main features of the editor are: Save and load to/from a file, place and remove objects from level. It seem simple, maybe it is, but I had to think a while before I started so that I made the easiest and fastest solution since we only had two week left before final. I also wanted it to be easy to add extra content to the editor so that I could send the new versions to our level designer and have him be able to load the levels he had already made and continue with the new features implemented.
   I first got the idea to have states, and that depending on which state was active you placed and removed different thing, and since it was such an good idea and worked, I didn't really think of a plan B. Instead of making a state_manager though I created a string called m_state and in the update and draw I had an if-statement for each state there was. Now I know this isn't good looking but I wanted a fast solution, not a good looking one!

I started with tiles and the first problem was: How should I select the tile I want? There was either a UI that showed all tile available where you could click to select which tile to place down next, or it was to cycle between all tiles with a keyboard button. Since all tiles are in one single sprite sheet I decided to do the first one. I drew the sprite sheet on the top middle of the screen and when the user clicked on it the editor found out which specific tile was clicked and set the current tile to that tile. When I clicked anywhere on the background a tile identical to the current tile was place there. I had some trouble with several tiles added on the exact same place but solved it by first going through all tile to see that there wasn't already a tile there. I also added so that the right mouse button removed the tile on the current mouse position.
   After the basics was finished I just added some tools to make things easier. The current tile was draw where the mouse was, the tile aligned them-self to the grid and a border was drawn around the current tile to be able see it clearer.
   When that was done I came to a little bit more difficult problem: How to save the map? The load map was easy since all I had to do was copy it from our main game and adjust it slightly, but the save was a little bit harder. All the tiles are stored in a vector instead of a two-dimensional array and thus I don't know which the most left, right, top and bottom tiles are. But after some thought I simply decided the go through the whole vector saving the lowest and highest of the x and y values in four variables. This also made it possible to not only work in a specific area but anywhere. If the top tile had a position of -512 it would have the position 0 in the saved file and all others would move down 512 pixels as well. To save them I had two for-loops with a third for-loop in them. The first two checked each position and the third went through each tile to see if it should be in that specific position and when a tile was found it was written to the file. If there where no tile there, simply write "9,9" to the file (when I wrote about the loading of levels I said "9,9" was chosen to represent an empty tile).

Finally I had the tiles finished, so I sent the version to our level designer and started working on the walls. The wall where a bit simpler in that they all have the exact same texture, but also harder since they had two points which had to create a perfect line. In the wall state update I made it so that the left mouse button set the starting point of the wall and the right mouse button created the end point. All I had to do was checking when an end point was placed to see if it had either the same x or the same y value as the starting point, but not both. For removing a wall shift had to be held down when right clicking and saving the walls was very simple since it didn't need to be saved in any order, just a loop with a single write to file line inside it.

After I had sent the new version away I started working on the props. These where like the tiles only I didn't have to align them in a grid, but I had to rotate them. No biggie and saved just like the walls.
   I fixed the vents after that, then the doors, player starting position, evidence and lastly the elevator. These last ones where really simple since I mostly copied from what I had written before. The only thing that is left are the enemies and their patrol pattern, which I wall do eventually. This editor have been great though! The time it have taken me to code has already been worth it since our level designer have had a super easy and fun time creating the levels. Now we are focusing on play testing and to create fun and difficult level for our game.

I don't have much more to add, thanks for reading and stay awesome!

The Tutorial

The tutorial is a great tool to introduce the player to your game and this week I've been working on the tutorial for our game.

On the first attempt to create the tutorial I wanted to explain the basics of our game; How you move, shoot, pick up evidence and progress to the next level. The tutorial was also meant to serve another porpoise: Explaining why you are there. I did not want to have much text in the tutorial, mostly images and preferably everything should be intuitive, but I failed on my first attempt.
   Firstly I limited what the player could do before he had advanced to a specific part of the tutorial, which isn't bad except I did it with movement. On the play-test day almost everyone playing the tutorial got stuck right away, some asking "Can't you walk?". This was obviously really bad.
   Secondly I wasn't clear with what the player was meant to do. At the start you are standing in front of a man and there is an image saying: "Move the 'image of a mouse' to aim". Everyone tried to walk with the character, who was immobile until a later stage, instead of aiming at the boss. We had to tell almost everyone what they needed to do at this stage, and that wasn't very good either.
   When the player aimed at the boss another image replaced the old one saying: "Click 'image of left mouse button' to shoot". However, this was so similar to the previous image that some players completely missed it.
   After the player had killed the evil boss it was fine. "Move with 'wasd'" was everyone familiar with and "Press 'space' to pick up evidence" was straight forward as well as the arrow pointing at the elevator when the evidence was collected.

There is one big thing however I did correctly with the tutorial: I completed it in time to be play-tested. I gained a lot of valuable feedback and now know how to create a better one!

So I had to fix these errors and create an easier tutorial. The first thing that happens in the new tutorial is that the character walks out of the elevator into a room with no guards, there is no UI to see either. If the player doesn't move for the first five seconds the image pops up telling the player to walk with 'wasd'.
    The player then progresses out of the room and walks into a corridor with a guard guarding. First now the player will see a circle around him and an image saying simply: "'Ctrl' to sneak". If the player press ctrl while walking he will see the circle getting smaller and that he moves slower. If he stands still the circle disappears. It will be easy to walk past the guard and advance into the next room.
   In the next and final room there is the evil boss. When the character walks in, the boss will say: "Don't hurt me!" and the character replies: "You don't deserve to live.". The 'how to shoot' image will pop up and the bullets UI will show as well.
   When the player kills the evil boss the tutorial will remind the player that the bullets can't be replenished. Also an evidence spawn in the room and the evidence UI is shown as well as the 'how to pick up evidence' image.
   The last stage of the tutorial begin when the player picks up the evidence and an arrow appear pointing in the direction of the elevator. The guard the player walked past before now enters the room and the last tutorial message is displayed saying: "'Shift' to run". When the player run the circle around him will increase considerately but he will be a lot faster and thus outrunning the guard will be easy.

I believe these changes will create an better tutorial which is more intuitive and teaches the player  more things about our game. Still, there is a few weeks before the project should be finished so I have plenty time to play-test it and ask others to try as well.

That's all for me this time. Thanks for reading and stay awesome!

Theory on doors

This week I've been working a little bit on many different things but I've had the most trouble with doors. Doors in our game are intuitive; the player can interact with a door if he is close enough, when he does the door opens away from the player. The door cast a shadow just like the walls but it gets complicated when it comes to the door-frame.

From the alpha play test we got some feedback concerning the walls; they looked like huge 3D walls. Some thought it was cool, others didn't. Some merely pointed it out and asked if it was out intention to have that effect. One suggestion to fix the 3D feeling was to limit the view when looking through doors, so this is what I've been trying to do.

My first thought was to take the same function as the wall shadow but move both the starting vectors (the two points on the door) further away from the player. I also thought the length by which the starting vectors would be adjusted would be dependent on the distance from the door to the player; this meaning a player far away from the door would only see that the door is open but not much through it, and a player close to the door would see as normal (no shadow from the frame at all).
   This sounded simple, but when I delved deeper into how to get the values by how far the starting vectors should move, the complicated stuff began. I realized it would look "off" if the vectors would move the same distance, so I had to figure out a way to get the both values correctly.

Circle theory

   After some time I had two different theories. The first one was to get the line from the player to one of the vectors and check where it intersected a circle with center in the middle of the door. Doing this for both the vectors would send them back further if they were closer to the player, this way it was also very simple to change the distance you could see by adjusting the radius of the circle.
   The second idea was to get the perpendicular line to the line from the player's position to the middle of the door. Then calculate where both lines from the player to each of the vectors intersected with the perpendicular line. This would give the same result and changing the distance would simply to take a point further back on the center door line.

Perpendicular theory

I never implemented this however. I have started working on it but when we got our new lighting system from our lead programmer this felt unnecessary since the player can't see far anymore.

I know this was a theory heavy post, but that's since I haven't made anything big this week this was the best thing I could write about. Thanks for reading and stay awesome!