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.

Escape - Group 4 - Week 6 - Audio Options & Credits

Progress on the main menu is going surprisingly smoothly. Not only did I finish visual functionality in one day, but practical functionality is almost finished as well.
Both music and sound can now be muted and the slider for lowering sound works like a charm. This however has been tested with only one sound file. There's still a lot of work to make this work for every sound file in the game.
Music and sound has to be dealt with individually, since they work differently. Sound-files are loaded into game process and can be played and affected directly in-game. Music however, are streamed separately from the game and aren't loaded. Because of this, coding a function that affects all music is a bit tricky. Thanks to the sound manager, sound-files can be collected into one single variable. In order to make the sliders work for music, there needs to be code that makes reference for each music-file instead.
Muting the sounds is done directly in the sound manager. If a certain boolean variable isn't set to "true", the sound files can't be played. The music unfortunately has to be coded individually to be lowered down to volume 0. This is a pain, considering that the music will still be running in the background taking up memory space.
Nowhere close to setting up gamma in the options yet, right now I'm focusing on the audio and credits.

The hardest part this week was to get the credits-tab to work, strangely enough. The problem was that apparently, deltatime hadn't been implemented in the template my fellow programmer had given me the first week. So instead, I tried to work around this by using SFML's timer-system instead. It's much harder than it sounds, over a hundred lines of code went into making a decently working credits-tab.

The finished work so far:

In fact, it isn't that surprising how I managed to get this much work done so quickly. Since I had a lot of help, too much help in fact. During all this time, I was pretty much coached by the other two experienced programmers on the team. It seems that I just transcribed most of the code right from their mouths. At times, they were the ones writing it down for me.

This gives me a bad conscience. It feels like I can't take any sort of credit for the work done during the past week. Although I did learn a lot thanks to their help, so far it feels as if I'm just in the way of their work.

Escape - Group 4 - Week 5 - Sound Manager

In an earlier meeting with the advising 3rd year student, it was suggested that I shift my focus off the main menu and start working on something with higher priority. "Sound manager" was on the list in the backlog and as lead sound designer, I chose to start work on it.

To make my job easier, I searched the internet for existing open source sound managers. There were only two existing managers, strange considering you'd find many open source managers for example: sprite-, object-, level- and so on.
The one I chose was apparently for an earlier version of SFML and I was having issues converting it to the current version. I posted a thread in SFML's official forums, later that evening I received my first answer:
"The functionality that you want to implement is already provided by SFML..."

His argument was that SFML was already designed in such a way that it wasn't necessary to have a sound manager. The day after, I solved the issues myself and got the manager to work. Was he right though? It took about a week to get manager to work, was it worth it?

Granted, now that the sound manager is in place, it's quicker to load sound files and requires less code. But it saves about 2 minutes of time comparing to loading sound files the usual way in SFML. In the long run, I may have wasted more time than saving it for the project. I could've focused on other elements or finished work on the main menu.

However, this may have allowed us to save disc memory when launching the game. Instead of having to load sound files in every separate state of the game, every same sound file can now be accessed in every state from the same source. This also makes our game's file size smaller. It may have helped  optimize the game.

It may have been a slight waste of time, but it also may have been worth it to make our game more functional and stable. What do you think?


Work on the main menu has been resumed and hopefully the options tab will be fully functional within the next week. So far, I've only worked on the visual functionality (such as working sliders to control sound-, music- and gamma-levels). Also need to consider to add a fullscreen option after seeing a certain "psychotic" person, react to the lack of that option in earlier projects...

Here's a demonstration of what I've accomplished so far (including sound manager):

Escape - Group 4 - Week 4 - Start Menu State

This past week, I've been working on the main menu. The first state that the player runs into when the game starts. First and foremost, I've been working on the menu's visual function. Doing this first will make it easier for me to program the practical functions.

I decided to work on programming the main menu, because of my little experience with C++ and programming overall. Graphics was done by Henrik Forsman. The design is inspired by 1950s commercial light signs and film noir.

So far, I've managed to load:

• Background image
• Main Buttons
  - Lighting up when hovering mouse over them

          - Lit up permanently when selected (clicked on), until any other button is selected

• Selection Arrows
  - Appearing left of the buttons when hovering mouse over them

          - Lit up and placed permanently when button is selected, until any other button is selected

• Title logo
  - Randomly turns on and off every half second

  

Background Image

Drawn by Henrik Forsman. It's a picture of the room the player starts in the first level of the game.

Main Buttons & Selection Arrows

I think it's unnecessary that we need buttons that turns on and off as well as selection arrows. For selected buttons, it would be just fine if they were permanently lit up. The arrows are unnecessary in my opinion, I'm following Theodors and Henriks direction however.

Title Logo

It took a while to make its on and off cycle balanced. It easily got too sporadic or inactive. I've tried to implement a buzzing sound that plays while it's lit.

The idea behind the menu's design is that anyone who's watched 50s or noir films or anything inspired by them will immediately recognize the style and be put in the game's atmosphere, even before playing.

Comments

I'm starting work on the options tab and the sound manager. I'm not really happy with the amount of content I've managed to implement so far. My lack of experience is no excuse.
The rest of the team worked on the first playable version of the game, while my work isn't even one the main priorities of the project.

The sound manager will probably be easy to program considering how simple SFML is to work with. After I'm done with that and the main menu, it's uncertain what I'll work on when it comes to programming. Since I'm given the roles of level- and sound designer, it might be time I start acting them.

The start and lack of Progress

Ever since we received our assignment in programming, it's been a mess. My lack of concentration, experience and patience has left a big blank in my work.
All throughout the holiday weeks, I haven't been able to make much progress. Not only because I forgot my earlier work and files, but because of uncertainty. I had no idea where or how to start. The Engine? Sprite manager? Particle effects?
Mostly graphics and sound-work were among the things I could contribute, even though it's programming what I'm supposed to contribute with. My group member ended up doing the majority of all the work.

Now that I'm back in Visby with my old files, things are starting to pick up. I managed to implement a sound manager and further worked on the graphics. The sound manager is mostly based on what assistant Jerry showed during a presentation.

Still, I'm almost as uncertain as earlier. I obviously need to refresh and repeat on earlier learnings. I feel as if I haven't fully grasped how SDL works. Not quite the time for this realization, since we only have about two weeks left on our assignment. Nevertheless, I will make the most of my efforts.