Pre-Beta Week

It's eight workdays unitl Gotland Game Conference(GGC) and the end of this schoolyear. This means that we have eight workdays to finnish our game Defunct. All the major parts of the game are in place but there is some small things that still needs to be done, and some things we will skip for GGC such as the level select screen we first planed on having.

Mockup of the level select screen.

Sounds

I implemented the sounds last week. As I said some time ago we are using the FMod studio plugin for unity so to play audio I  need two things: The Event files and the Bank Files.

Events are audio files that have special parameters that control them such as a velocity. Bank Files are files that contains links to the events, so to get an event we have to load a bank and then request an event.
When requesting an event we get a eventinstance which we then use to play sounds.

I created a class called SoundController that (guess what) controlls the sounds, when something wants to play a sound it calls the .PlayEvent() functions which takes a enum as parameter. Preferably this function would take a string since FMod Studio has string bank where you can link events with names, but we couldn't get it to work and it wasn't worth sinking any more time into.

I also created functions that stops, pitches fades and sets the volume of an event.

Feedback

Mikael created a particle effect for when you go out from a checkpoint that I then added to the checkpoints, and to emphasis the speed of it I also play a bit more with the FoV of the camera as you leave the checkpoint.

Directly after leaving a checkpoint

I also did the same thing but with a much much smaller FoV increase when you pick up a small boost, since we've feelt from the start that you don't "feel" the speed you get from the small boosts.

Camera

I spent some time on the camera this week smoothing it up. I realised that i used the physics player to calculate the position of the camera, which is quite dumb since it's moving really jerky since the physics player doesn't tween between the positions. I simply changed it to the graphical representation of the player for all the calculations of the camera positioning. And other smothing and rotation fixes.

Small Things

The small things of this week are some fixes with the ships, and multiplayer.
I chaged the ships up from patrolling to just going forward because it should look like they have a goal, not aimlessly flying about. I made it so that they have a spawnrate and a min and max height where they can spawn, max, min speed that they can have.

I changed the way the checkpoints give force, to balance the checkpoints with the level design we wanted to give less force to the player that already have alot of speed, so i changed them so that the level designers can sett a "fallOfCap" if the player has a velocity above this cap it will get less force that if it was below this cap. The force given is reduced by a variable called "fallOfRate" for each percentage above the cap the players velocity is.
Then I did some other small things such as fixing the restart in multiplayer, tweeked with post-processing effects and things like that.

That's all for today, goodnight and thanks for reading.

-David Forssell

The week of XInput, Checkpoints and "Destructible objects"

The week has come to an end, and for once I thought I whould get this blogging thing out of the way in time, so here I am.
This week I've been doing alot of different things, I re-did how the checkpoint boosts worked, I implemented XInput, a Xbox controller library. I linked our multiplayer lobby to the actual gameplay so the multiplayer works, and a lot more.

Checkpoints

So we got some feedback during the alpha, and one feedback we got was a smal amount of players didn't get the checkpoint boosts we had. In this checkpoint system you hold down a button to charge a boost, and then when you release you gain the momentum you've charged up. So to simplify this we decided to redo them so that they charged themselfs and when you pressed the button you got the momentum.

I personally didn't like this change, since I feelt that we keept the player passive and the charging lost its charm when you didn't charge it youself, but I still decided to give it a chance. So I changed the checkpoint boost to how we decided and we tried it on some people, and none of them liked the changes we did to them.

As I feared I made the player passive, and we decided to revert them to the way they were before. I think that people will understand this system when it's explained to them: "hold button-charge, release-get speed" is not that hard to get.

XInput

XInput is a library for Xbox controlls "But David, you are making your game in Unity doesn't that already have controller support!? Are you a moron!?" Glad you asked random person on the internet, yes we are making our game in the Unity engine and yes it has controller support, BUT it doesn't have full controller support since it can't make a controller vibrate. However it can make a phone vibrate, lazy lazy Unity...

Implementing XInput was easy, only download a package and import it, the only irritating thing is that visual studio doesn't realize that it's in. It gives away errors but unity can still compile and run it like a charm.

To set vibration on a controller I simply have to write: "GamePad.SetVibration(controllerIndex, leftVibration, rightVibration);"

I started with vibration for the Pumping feature, a small vibration when you pump in downhills and a large staggering vibration in uphills, sortof like a coughing engine. This is to make the player feel staggered when pumping in uphills to make them stop, since this makes them lose speed.
I then added a vibration for when the checkpoint boost is fully charged to tell the player to let go, and a small vibration for when the player picks up a small bost, to emphasize the speed increase.
The last vibration I added was for landings, When the player loses alot of speed in its laning I vibrate the controller roughly.

Small things

I created a button that you can spam when you have low speed to gain some speed, I'm not quite sure why we have this, since the problem we had that led to the creation of this button is that "people doesn't respawn at checkpoints when they lose speed". I guese it is to allow the people that don't want to get a good score and only want to cruise to do so.

Petter had made a script that gave objects with a specific tag a rigidbody when you hit them, to make things "destructible", but they didn't reset when you went back to a checkpoint and since I made the respawn system were we reset all the boosts, sparks and so on, I also made the physics objects respawn.

All I did was to make the "PhysObjects" register themselfs in the respawn controller with their position and rotation when they got activated, when you respawn at a checkpoint the respawn controller then removes the rigidbody and places them back at their original position with their original rotation.

I linked the multiplayer lobby Petter translated form my code to the actual gameplaye scene.

To load a different scene in unity you have to change the level prefix of the network, this is just a simple digit that reprisents a level. This is so that the network can filter out any information sent from another level, in adition to that you can also force the network to stop sending information while loading a scene to save bandwidth.

I also created some small scripts not really worth talking that much about, such as a patroling script for some ships that we will have flying over the world.

That's all for today, goodnight and thanks for reading.

-David Forssell

Alpha Footage

Here's the footage I said I would upload, hope you like it.

Fmod

The primary artifact I've been working on this week is to implement FMod studio support.
FMod studio is a sound design tool for games that quite recently added support to Unity. FMod studio is not to be confused with the FMod library which Unity already uses internaly to play sounds. The primary use of FMod studio in this project is that we can add variables to what FMod studio calls "Events" the sound designer then uses these variables to change the way the sound behaves. As a programmer I can then access these variables in Unity and change them in runtime to change the sound.

For instance, if we have a event called "Driving" this event has the variables:
Material - For the material of the ground
Velocity - For the speed of the object
Wind - The wind where the object is
Pitch - If we want to pitch the sound (for slomotion)

The Material variable then has some "triggerzones" when it has the value 0 it has a dirt sound, when it passes 0 to 1 it automatically crossfades between dirt and metal since that is what the sound designer has told the sounds to do in this triggerzone. and if we instead go from 0(dirt) directly to lets say 5 which  is stone it will corssfade from dirt to stone, skipping all the materials in-between.
When the Event then is exported it becomes one file that a programmer easily can access all the variables in, instead of having 500 different sound files and creating a system that fades between them when we want by ourselfs. It also means that the sound designer gets exact audio experience it's looking for, since it will sound exactly the same in the game as in their project.

Small Things

So just as the last week this week I've been doing alot of small scripts for the artist, Mikael our lead artist wanted to have some scripts that rotated things towards the camera and panned textures, pulsates lights, making objects move towards the player and so on. Not really that much to talk about those things, they are all basicly 1 row scripts and does exactly what their names suggests.

I also added an aura around the pickups to emphasize their pick-up range, and added the textures on the player.

I'll probably post some video footage later this week.

That's all for today, goodnight and thanks for reading.

-David Forssell

Checkpoints and more Networking

Another week has passed and the last week there has been alot of little things to do.
First of the Network HUD I talk'ed about last week was put on hold for more importent single player features and fixes. Oh and we changed the name from Open Circuit to Defunct

Checkpoints

I've redone the respawning system since Robert thought it would be cool to go into this sort of overview where you could toggle between all visited checkpoints and respawn at a selected one.

Is' still a little buggy and some changes will be made, but I liked the general idea more than the system we had previously where you pressed a button and just respawned. However we are thinking to add a quickrespawn button for when you want to respawn from the last checkpoint as fast as posible.

Networking

So the things I did with networking this week was to make it so that when player picked up a boost it disappeared for all the other players aswell. And that's about the networking I did last week, since we had an internal alpha last week the singel player features took some priority.

Small Fixes

I've been doing a lot of smal fixes this week, making things for the artists, for instance if they want something to spin or to make a particle effect start when you pass an object and so on.

That's all for today, goodnight and thanks for reading.

-David Forssell

More Camerawork and Spontaneous Networking

It's week 17 and it's three weeks into the big game project, there has been a lot of talk in the group as of late but mostly about level design. But since I'm not one of the level designers I'm not going to talk about that in my blog.

Camera

So the camera has been a top priority as of late, the last two weeks I've been trying out some different camera models. The first one i tired out was a free-rotating that the player had complete controll over, but I also made it snapp back to it's original position behind the player when it hadn't been moved in a while. I then restraint the camera so it couldn't go below the ground and not rotate above the player. Having That whould make the player upside-down or the camera would have to rotate it in the Y-axis make it face-up and I didn't think that would look good.

For the air camera I ended up making it look towards the spot the player would land, this was easy since Petter already calculate the ladningspot for the movement code. All I had to do was to calculate the vector between the camera and landingspot, normalize it and move the camera back x times that vector from the payer to get a nice overview.

HUD

Jonatan feelt that we needed some sort of "overview-button" that when pressed zoomed out the camera and gave the player a huge overview of the area. Robert then came up with the idea that we could display the some sort of HUD on that overview aswell. So i set out on creating this, when the left thubstick is pressed and hold the time slows down and the camera zooms out, the HUD then fades in and shows the player the only info it could want to know.

Networking

So last tuesday we spontaneously decided to add co-op into the game, since this was something that mostly needed programming. I don't have that much to do at the moment other than to create small scripts for the artists like when they want something to spin or a texture to pan and so on. So with that in mind and after countless requests from playtesters to add multiplayer I started to work on the multiplayer. Unity's networking is really grateful to work with and after one day I had a working build.

What I will be working on this week is to reduce the lag and adding some HUD that indicates where the other players are, since you can loose eachother quite easy as it stands.

These images are quick mockups of how that HUD might work.

Wether these HUD's will show at all time or when the player clicks the left thubstick is still under discussion, perhaps we'll make it an option.

That's all for today, goodnight and thanks for reading.

-David Forssell

Big game is starting.

Prologue

This week the course "Big Game Project" started, during the weeks leading up to this project we've been working on a concept that Jonatan Keil proposed with the working title "Open Circuit" and thus the group Freshly Squeezed was created. The game is to be created in the Unity engine.

(Click here to read the concept pitch,
The colour errors are due to Google Drive)

Last Week

My primary work last week has been with the boost that are suppose to drive the player forwards, I've also done some work on the checkpointsystem and the mechanics of the checkpoint boost. I've started to work on the camera effects to emphasize the feeling of speed.

The Boosts

(Programming art)

There are three types of boosts, the small boosts used for guidence and the weakest of the boosts. The activation boosts are less common but can be activated when the player chooses with a great bust of force. Lastly we have the checkpoint boosts, when the player enters the area of a checkpoint boost they can charge up a boost that will sling them in the direction of the vector between the player and the boost station.

The small boosts are very straight forward, when the player collide with them they instantly give the player a small amount of force in the players direction, since we're using Unity's rigidbodies all I have to do to accomplish this is too add force to the players rigidbody with the players forward vector.
The activation boost works in a similar fation, but instead of adding the force instantly it adds to a pool of boost power that the player can activate when he/she chooses, upon activation the force is added to the rigidbody.

The checkpoint boosts are the most complex of the boosts but still not that problematic. When the player enters the area of the boost, the time is slowed down, the player now start to charge a boost by holding down a button. The amount of charge is shown by the field of view increasing(as shown below), the output direction is shown by the yellow line on the ground(emphasised with red in the picture below), when the player releases the button he/she will be slingshot in this direction.

(I'm no artist, as you can see)

We had a various of ideas for the checkpoints that I concepted and tested, one idea was that when you entered the area of the checkpoint you lose control of the player and start to controll the output-direction arrow. But to make this feel good I had to add a diablo-esc camera perspective so you gott a better overview of the arrow, however we felt that this checkpoint model took you out of the gameplay and ruined the "flow" that is the key feature of this game hence we went with the other checkpoint version.

The Camera Effects

So I talked a bit about changing the FoV(Field of View) of the camera, and this is right now also our primary speed effect. Currently I change the FoV of the camera depending on the players Velocity, clamping it between 60-120 FoV. I also add some Bloom and motion blur to the camera, however all of these effects are subject to change.

The Checkpoints

Right now we are talking about how we want to handel the Checkpoints, we are currently leaning towards a model where you can toggle between all the checkpoints you've passed during your playthrough of the level. So if you want to go back more than one checkpoint that is entirely possible. When going back to a previous checkpoint the time is reset to the time you had when passing that checkpoint, however a penalty is added to your time, stopping you from just reseting form the checkpoint over and over again.

Fog of War

The last thing I've been working on is the FoW(Fog of War) for the game, in the game's level selection screen we are going to show a preview of the map with Fog of War where you haven't visited. I accomplish this by splitting the terain up in parts, then register when the player has visited one of these parts. This data is then converted into a texture with transparency where the player has been.

What's left to do is to add alpha-gradient to the borders of the visited areas.

That's all for today, goodnight and thanks for reading.

-David Forssell