Escape - Group 4 - Week 9 - Level Editing - Part 2

3rd week working on the level design. With two weeks left on the project, I was supposed to spend the rest of the time to finish the last, largest and most complex level in the game. Instead, I spent most of the week to fix a mistake I missed last week.

When using the level editor, I sett the walls and outside boundaries by them dividing it into rectangles. I sett these rectangles by choosing coordinates for the upper left corner and the lower right corner. It is imperative when setting the rectangles, that I choose the upper left corner first.
Here is where I made a mistake. At one point, I did the opposite and chose the lower right corner first instead.

The reason why the walls are set like this, is because of the lighting- and collision system in our game. They works best and is most bug free when the objects are square shaped. So when I sett the rectangles, they're divided into a number of squares side by side with each other. The level editor is programmed to calculate the distance in width and height between the upper left and lower right corner and fill the space in between with equally sized squares.
So when I chose the lower right corner first, the level editor started to calculate infinitely in vain to find the upper left corner. This resulted in a oversized (366 MB) and corrupted TXT-file.

I didn't realise this mishap until the week after and so I had to start work on the walls in the earlier level all over again. Luckily, I had saved the TXT's in intervals and I didn't have to start everything from scratch.

As mentioned earlier, I'm now working on the last level of the game. The earlier levels took one week each to finish, but in comparison the last level has double if not triple amount of objects and triggers to place. In order to finish the last level as well as have enough time for the reports, I will have to work more intensively than I've ever done in the university line so far.

For 3 weeks have I focused on the level design and not so much on programming per say. It's what I get for volunteering to do this monotonous job. I just hope it doesn't effect my results as a programming student when it's time to write the reports.

Escape - Group 4 - Week 8 - Apparent Issues

Still working with the level editor, since we underestimated just how time consuming the process could be.
Another problem became apparent at the play-testing session last Monday. There was no way to test the actual levels. The lead programmer wasn't able to generate the levels via the TXT's until a few hours before the session. And so, testers would see weirdly placed furniture, empty rooms and run into invisible walls. Another problem was that if an object would be set so that the light wouldn't affect it, it would turn invisible.

The misplaced objects was an easy fix, but testers also complained about lacking level design. Saying that the levels were too void and that they entered the game not feeling motivated enough. The goal wasn't obvious and the NPC's weren't threatening enough.

It's true that there really isn't much that motivates the player to hide from the NPC's and get to the exit safely. After testing the game personally, I noticed that it was too easy to outsmart(-run) the NPC's. This might encourage players to just rush through the levels, rather than staying hidden.

How do we fix these other problems?
One suggestion might be the use of a time limit. The player has a certain amount time to complete the objective and find the exit. This might motivate the player a little more to reach the game's goal. This however might not motivate them to make use of stealth, but rather give even more reason to rush through the level.
The NPC's needs to pose more of a threat. In order for the guards to shoot, the player needs to stay within the guards line of sight (flashlight) for a certain amount of time. This is usually enough time for the player to escape and get out of their line of sight. If succeeded, the guard will simply spin around and later continue with his usual patrol pattern.
A suggestion to fix this, is to apply a permanent consequence for being spotted. This was suggested early in the development. The guard will report to the others on the level and every other guard will start to look for and chase the player.
The problem with this solution, is that the stealth gameplay would come to an abrupt stop. There would be no room for mistakes and the difficulty would be raised immensely.
If the player was able to hide from the guards and there would be a cooldown for the alarm raised, it would be less of an issue. However considering the difficulties of programming AI and the amount time left on the project, it's not likely this will make it into the final version of the game.

There's a lot of problems, many not even mentioned that needs to be fixed. Many of these problems weren't even noticed by us, until the play-testing session. Which proves even further the importance of proper outside play-testing.

Escape - Group 4 - Week 7 - Level Editing

After a few delays, the lead programmer gave the "ok" to start using his level editor for the project. As per the SCRUM-meeting for the week, I took on the task of using the editor to build all planned levels. Little did I know what lied in wait for me.

Using the editor and building the levels (or "sectors", as we call them for this project), goes like this:

1. A mockup of the level done by the graphics designers is loaded as a template.
2. Walls and outside boundaries are placed by setting coordinates for upper left and lower right corners of rectangles.
3. Props like furniture and other environmental objects are placed by setting middle point coordinates, angle in degrees and setting full, half or no light transparency for the games lighting engine.
4. Setting up the guards (NPC's) spawn points and waypoint patrol patterns.
5. Placing key-items.
6. Setting player spawn point and level exit.

After almost a week, I'm still working on one level and I'm still on the second phase. There's no undo-, move- or delete-function for the objects placed in the editor. The saved data is in shape of TXT-files, so every misstep has to be fixed manually by editing the TXT's.

In order to get the most accurate coordinates, I open the mockup pictures in Photoshop. I place the the objects as layers, read the coordinates and angle degrees. Then I switch back to the level editor and place the objects using the data from Photoshop.
The level sizes varies from 7000x7000 to 10'000x10'000. Following the mockups close to pixel-perfect is a very time consuming process and it became obvious that I wouldn't be able to finish this task by myself. Therefore, one of the graphics designers was appointed to help editing the other levels.

There are two reasons why we chose to build our levels like this:

• We wanted to avoid using a tile-system. We didn't want the levels to have a readable and blocky pattern, but to have a more irregular and interesting feel and design.
• In order to make our lighting engine work as well as possible, the walls and boundaries needed to be set into side by side squares. When setting the corner coordinates for the walls, the editor divides the set rectangles into a number of differently sized squares.

It's monotone and very time consuming work. But in order to give the player an experience as good as possible, I'm willing to put up with it.