Post BGP 2015 – What went wrong (part one)

Hello!

I think I’ve been pushing this in front of me long enough now. This will be a bit uncomfortable for me to write about, but it needs to be done. Hopefully I can help someone avoid at least some of the mistakes that I and my group made during this project.

Lone programmer

The first thing I’d like to bring up is the fact that I was the only programmer on the team for most of the project as the only other coder unfortunately had to leave the team at the start of week three. The obvious problem with this is that I now had roughly twice the amount of work to do but no extra time.

Another problem that might not be quite as obvious (and a bit more difficult to explain) is the fact that I also had to plan the structure of the code all by myself. This meant that I could not focus my efforts entirely on what I was coding at the moment. I had to keep the entire code structure in the back of my head at all times, as well as the fact that I had to do all of it. Whenever I was working on one part of the code, say the movement mechanics, there was no progress at all in any of the other parts.

Yet another problem with being the only programmer is that you don’t really have anyone to discuss coding solutions with. You lose a lot of potential feedback. There were other groups of students that I talked to on occasion though. We also had something called quality time every week where I would meet one of the programming teachers and discuss development issues and potential solutions. This helped out a lot. In hindsight I wonder if I should have put more time into discussing code with students in other work groups.

Lastly, the fact that I became the only programmer in the group without warning also made things harder, as I had little time to adjust my code planning.

Bad pipeline

Before moving on I would like to point out that the pipeline I am talking about was my group’s production pipeline, not to be confused with other pipelines such as Unity3D’s rendering pipeline (http://docs.unity3d.com/Manual/SL-RenderPipeline.html).

The main problem with our production pipeline was that roughly half of the group’s members were not connected to the project’s source control until there was only one or two weeks of production left. Some didn’t even have the Unity3D engine installed on their computers until then.

This meant that whenever an art asset was made it had to be added to the game through me, which took time and focus away from programming. It also meant that if there was something odd with the asset when imported to Unity3D it either had to be fixed in-engine (by me once again) or I had to tell the other group members this after which another asset was made and then sent to me so I could import it once again.

This is obviously a very sub-par production pipeline, especially considering that I really needed to focus on coding. Once we got a proper source control going things went much smoother, but it was a bit too late to save the project unfortunately.

That is all I have for now. Part two should be up in a day or two if everything goes well.

Cheers!

BGP 2015 – sixth week: Development issues

Hello!

This week I started by giving the camera some simple movement behavior. Basically I make it follow the player’s position (with a certain offset) and rotation though somewhat slowly so that it’s movement becomes more smooth rather than sudden and jerky. I am mainly making use of ‘Slerp’ and ‘SmoothDamp’ for the camera’s movement.

I’ve also managed to get the direction correction for the movement to work as intended. What I had missed was that I needed to make use of conversion between local space and world space in the engine.

Here is a copy of the sample code if it’s hard to see:

1. // C# / UnityScript
2. var yVel = rigidbody.velocity.y;
3. var localV = transform.InverseTransformDirection( rigidbody.velocity );
4. localV.x = 0.0f;
5. localV.y = 0.0f;
6. var worldV = transform.TransformDirection( localV );
7. worldV.y = yVel;
8. rigidbody.velocity = worldV;

Taken from:

http://answers.unity3d.com/questions/412078/keeping-forward-velocity-always-in-the-same-direct.html

Lastly I encountered a problem with the rotation boxes (triggers that will rotate the player automatically, but only in the x-axis and z-axis) when they are used in the actual level we were going to use for the Beta.

For some reason they stop working properly when their local z-axis is aligned with the world y-axis. I thought I could fix this by making use of local rotation values just like I did with the movement but it ended up making things worse as all rotation boxes  regardless of placement stopped working properly.

Worst case scenario we will have to move on without any automatic rotation as there isn’t much time left.

Cheers!

BGP 2015 – fifth week: Trouble with player movement.

Hello!

This week I’ve mainly been working on the player movement. I tried making it more controllable by the player. This was done by changing the direction of the rigidbody’s velocity to a forward vector multiplied by the magnitude of the old velocity. However this meant that the parts of the velocity that made up movement other than acceleration, such as jumping or strafing, also became a forward vector. As such jumping, strafing, tackling and gravity was ruined, but the player did get better steering control over their vehicle. By drawing mind maps of the movement function and analyzing it, I tried to get the redirection of gravity apply to acceleration only while the other velocities, such as jumping and  strafing, were unaffected.

In the end, however, it turned out that using the old movement (without the redirected acceleration) with a largely increased drag on the rigidbody, from 0.5 to 2, worked better as it also gave the players control without affecting the gravity, jumping etc…

The big question now is which form of translation the movement should be made up of, by adding forces or affecting the rigidbody’s velocity directly? Add force might be the better alternative as using that means I will interfere less with Unity3D’s own physics engine, but I need a proper level to test the movement on now.

Cheers!

BGP 2015 – fourth week: loops, turns, rotations & illness

Hello!

This week has been pretty bad for me because I’ve been ill for the most part and as such have not been able to work as much on the project. It really does wonders for your stress levels.

I have been able fix the custom gravity effect for loops and turns by making prefabs that are essentially trigger boxes that apply a gravity effect on any players within them. The direction of the gravity effect is determined by the rotation of the object itself (which is invisible), or rather the direction of its local y-axis is the inverse of the gravity direction. This way anyone, not just programmers, can place and manipulate the custom gravity by rotation the objects and transform their trigger colliders. Indeed, they could even replace the box trigger colliders with trigger colliders of different shapes if they so desire, what’s important is the game objects rotation and that it has the gravity script attached to it. The script also has a public variable for multiplying the gravity strength if the need should arise.

This way it is possible to place several gravity objects with different rotations along the turn or loop in order to make it’s custom gravity.

I’ve made a similar type of game object that takes care of rotating the player as the level twists and turns as the players are not to be able to pitch or roll when on the track. They work in principle the same way as the gravity objects except they affect the players rotation instead. The rotation is handled by an individual type of object since the rotation and gravity direction don’t always coincide, they need to be independent of each other. Compare the image below that shows the rotation boxes for the loop with the image above that shows the gravity boxes for the same loop.

I’ve also managed to clean up some of the code. Previously the input form players and the player movement was in the same script so I had to make one for each player. Now those are separated, which should help make things easier from now on, at least when developing the player prefabs.

Cheers!

BGP 2015 – thrid week: minor crisis & Pre-Alpha

Hello!

This week the only other programmer in our group had to drop out due to personal reasons. This left us in a minor crisis since I am the only programmer in the group now, though one of the other team members know some basic C# scripting in Unity3D which will hopefully help me somewhat. The focus this week was to get a pre-alpha build ready for play testing.

I’ve abandoned using ‘actual’ hovering on the vehicles for now in favor of a collider placed under the actual game object to make it appear to be hovering. After some iteration it turns out a cylindrical collider with locked rotations seem to work the best.

This includes moving between track pieces of different rotation.

I was going to try and implement a spline editor following a tutorial I found, but there is no time for that now. Instead I focused the last days of the week on making the alpha playable for two people on split screen using a game-pad each.

Cheers!

BGP 2015 – Second week: Swithcing to Unity3D 5 & First playable

Hello!

This week we decided to switch to the Unity3D engine. The reason for doing this was because we programmers could not find a way to make a custom gravitational effect work with the player movement because of how Unreal handles forces in relation to character controllers. We programmers were also inexperienced with the Unreal engine, which was also a factor.

We do both have experience with working in the Unity3D engine however, so after talking to the rest of the group about it the switch was made.

Unfortunately the other programmer in the group came down with the sickness so it fell to me to make the new gravity work as well as the input and movement mechanic for the game as the deadline for our first playable was this Friday.

The road segment that the player is pulled towards via the gravity effect is determined by trigger colliders. This currently has a problem whenever triggers overlap as the game switches to its default gravity whenever a road segment’s trigger collider is exited.

Through iteration I was able to create a finally create a gravity effect on road segments by taking their Transform.up vector and inverting it. This way it does not matter which way the road segment is turned or rotated, as long as the player is on the right side of it and close enough to it there will be a gravitational pull towards the current road segment.

I still do not know how to handle road pieces that curve tough I am thinking about attaching invisible objects to the road segments and using them as the gravitational center instead of a Transform.up vector.

Using a raycast straight down from the player to determine if there is a custom gravitational pull would be an alternative were it not for the fact that players that are rotated the ‘wrong’ way should still be affected by the gravitational force as long as they are close enough to the road segment.

As it stands a first playable is done, however the gravity effect and movement still needs more work.

Cheers!