The justification for removing the infernal split screen.

In this blog i will talk about why we decided to remove the split screen aspect from our game. As i've said in other blogs; the game concept we chose for our shooter was "Bullet_Hack" which had the main theme of split screen.

In the beginning we tried to keep as close to the concept as we could, but after failing at maknig the split screen as it was described in the document we moved away from the idea and tried a different approach; by using a pseudo split screen where all the scenes in the game only appeared to have two screens but only one screen was used at a time.

During a majority of the development cyckle we designed our game with the split screen in mind. Everything from the sprite sizes, level design and even the amount of health the player would have was a by-product of the split screen. The longer in in the development we got we started to doubt the split screen on several levels. We doubted how the game played, we doubted how it looked aesthetically and we doubted the the sizes of the sprites. So almost everything in the game we doubted because of the split screen.

It all came to a head during the beta playtesting session where one of the most consisten critiscisms we recieved were about the split screen and how ugly it made the game look.
After the playtest we were worried the game would never be any better because we were stuck with the split screen because it was so prominent in the concept document. Fortunaley we asked Marcus about it and he said we could remove it eithout any problem. So we decided to remove it and see if the games quality improved, and to our delight it did.

With the split screen gone we could finally improve our game to a point where the doubts we had wasn't centered around the damned screens. Now our doubts is about how well the art looks and how it conveys the mood we aim to set in our game (the same can be said about the gameplay).

The curious case of teleportation.

this week I worked on how the player would be transported through the room.
at first we just wanted to delete the door so the player could walk freely between the rooms. This showed itself to be quite bothersome.

To explain how our game works. We're designing a game called "Bullet_hack" wich is about a spy trying to infiltrate a compan to get information about them. You play as the spy and try to hack doors to get to the main server.
You hack the doors by playing a shooter game where you destroy the enemy spawn points to
progress to the other room.

since we change scenes to initiate the hacking game deleting the door will not work since the loadscene(); function recreates everything in the scen you load. So deletion is of the table.
So i decided to try to see if i can get the player to teleport between the rooms upon interaction with the door. This was a huge failure on my part.
I tried using PlayerPrefs to save the players position and change it whenever a level was loaded. In hindsight, this would have caused me a metric ton of problems  and work in the future since it meant that i would need to specify exactly where the player would spawn after every level.

So after a week of frutration I asked Håkan for guidance. Five minutes later the telportation was fixed. He told me that all i ned is a static string and several empty gameobjects called "Spawn_point" (with a number at the end) and tie the players position to the Spawn point and the string as a tool to specify wich spawn point to teleport the player.
This worked and I still slam my head into walls or any other hard surface I find because it's so simple and i didn't think of it at all. In my defence i tried to find answers online, but everything i found pointed me in the direction of PlayerPrefs and, strangely, they also pointed out how bad they are for teleportation and in general. This should have been a big tip off that whatever I would potentially do with the PlayerPrefs it wouldn't be worth the effort when there's simpler options available.
The lesson I learned this week; in the future I will try to ask the teachers if I have problems with anything instead of trying to force google to tell me.

Options menu and the troubles following it.

In my last blogpost I talked, briefly, about how i was making the main menu. Since then i've put my focus on doing an options menu with proper settings like, resolutions and volume control.
In the beginning i checked out tutorials for how to make option menus and how to implement different options for the entire game and not just one scene.

I started in a simple manner with implementing the fullscreen wich was suprisingly simple. Literally three lines of code was all that was needed for it to be functioning (I'll never get over how simple everything seems to be in unity).


What I thought would be the hardest thing to implement was resolutions since different computers have different settings for their resolutions based on their graphics card (I think it's the only thing resolutions are based on but i can be very wrong).  The reolusitons itself was simple to implement, I just made the computer check what resolutions it had available and stored them in an array.
The current problem with the resolutions are that most of the resolutions appear several times in the list and i can't figure out how to make it so that it only appears once.

The volume controls showed itself to be a problem. The volume control itself was simple, just tying the value of the volume of the audio source to a slider was simple, but to make it work over the entire game eluded me. Now it only works on the main menu. I'm thinking that  putting all the music and sound effects into prefabs will remove the problem, but i've yet to try it.



I also worked on a proper pause menu for the game but it's just all the scripts and buttons from the main menu put in the scenes. The only thing i added to the pause menu that isn't in the main menu is a pause script to keep the game from running while you play and avoid unnessecary frustrations.
Although i'm looking for a way where you don't need to put the paue menu into every scene to be able to use it.

Simple main menu and plans for the future.

This week have been fairly slow on the programming front. Since we're close to the alpha deadline everything we've done is all the basic stuff that we need for the alpha to be able to focus on refinement and level design for the beta.

All I've done this week is creating a basic main menu and GUI. This only posed a problem due to my own inexperience with unity (a very common problem that makes repeate apperances during the entire developement cyckle and I suspect will make several more) which meant that i had to follow  unity tutorials and didn't really do anything that differs from the instruction given in them.

Aside from the GUI and menus, me and Kevin made plans for what has to be done code-wise in the beta development cyckle. The plans consist of moving the spy character through the rooms during the stealth phase of the game.

Just to quickly explain our game before moving on. Our game is "Bullet_Hack" which is a game where you play a spy trying to get to the server room in a building to steal all of the intel from it. The game has two phases one where you walk around inside the building and collect power ups to use in the second phase, which is the hack phase where you try to shoot down spawn points to unlock the door you try to hack.

Right now we have a bunch of scenes that each holds only one room each (see picture above), and we want to change it so we have one scene that holds the entire stealth level with doors leading to different hack levels, almost like a level select screen.

The problem we faced was how we would move the player between the rooms while using the doors to start the hack levels. There were two options open to us; we could make it so the doors open and the player will be able to move between the rooms without the door as an obstacle after the first hack. The second option was to teleport the player between the rooms when a door was succesfully hacked.

This is something I asked Håkan about and he gave the advice that telporting the player was the better option because we wouldn't need to hide the gaps and irregularities our rooms inevitably will have whenever a door was opened.
With this advice Kevin and I settled for the teleportation idea.

5SD06 First post. Talking about the camera issues.

I'm Tobias Holm and I'm the lead programmer in the group "Fenrir".
In this post i will discuss the problems I had with the camera system in our game.


Our game concept is "Bullet_Hack". The main theme of the game is a split screen system where you play a pseudo stealth game on one screen and a space shooter, while you hack doors and other things, on the other.

This sounded fairly simple to create when we first started on the game, but I quickly found out it was anything but simple. Since I'm the lead programmer it was my job to make the cameras.
What I wanted the camera to do was to switch between eachother on player input. this proved far more difficult than I imagined.

I struggled for a long time with the cameras and nothing i found on the internet helped, most of the stuff i found was outdated and no longer aplied in the newer versions of unity. Indeed, the cameras turned into the bane of my existence for TWO weeks before I decided that what I wanted the cameras to do was outside the extent of my coding skills and thus i decided to make it pseudo split screen instead.

 To create a pseudo split screen I just change scenes to another scene with the exact same camera setup when the player gives the correct input.

In this picture you see how the camera setup is. It does indeed look like split screen, but you can only interact with the red circle and the blue rectangle. The lower screen will show a static image or an animation showing progress and what power ups ypu have.
 To make it look like split screen i just change scenes when the game should change the screens.
This works on a fundamental level but I will try to make the cameras work the way I originally  wanted for the beta deadline but I will not make it a priority or even work on it until we are comfortable that we are almost done with everything we need for the deadline..