Post BGP 2015 – What went wrong (part two)

Hello!

Continuing from the last post, here are the other things that went wrong with the BGP project (from my perspective at least). Note that I’ll be using the words ‘workplace’ and ‘office’ interchangeably when referring to the room that was set aside for my group to work on the project in.

Working hours & presence at the workplace

The working hours for the group were initially set, from 9:00 / 10:00 to 17:00 / 18:00 (some flextime was allowed). This would have been all well and good if everyone had kept these working hours. However, as time went by, people started showing up a later hours, usually after 12:00, meaning they had to stay until after 18:00 to get their work done for the day.

This meant that most members of the group didn’t work in the office at the same time. This makes collaboration more difficult. Working in an office that is mostly empty can also be quite stressful, as I realized far to late. You don’t know what the other members are doing and you have no firm grasp on the status of the project overall.

This became even worse when some of the members stopped coming in to work all together and worked from their homes instead. This was tolerated initially as it was believed that more work would be done faster if they were allowed to work at home.

In the end I believe it did more harm than good due to the lack of collaboration that resulted from the lack of presence at the office and the influence this had on the stress factor.

Failure to utilize SCRUM & daily stand-up

The group initially had SCRUM documentation set up as well as a daily stand-up routine, which was only kept during the first few weeks, after that the daily stand-up fell out of practice. This was probably due to the lacking presence of group members in the workplace. That most group members didn’t follow the working hours if they did come to the office made this even worse. The daily stand-up routine did come back into practice somewhat towards the end of the project with some help from the school, and it did help increase production but in the end was not enough, unfortunately.

The SCRUM documentation was hardly ever used after being set up, even at the start of the project.

This might have helped me keep focus on each task if I had stuck with it, but it is hard to say what impact it would have had. Even if I didn’t use the scrum I still documented everything I did as best I could in a diary of sorts as well as using the ‘sticky notes’ application in Windows.

Wrap-up

That is all I can think of. The problems were mostly related to stress and disorganization, not to mention having a team member drop out unexpectedly. What I took away from this was mostly the strong effect of being alone in the workplace had on my stress. Even if some people work better individually, they group as a whole will most likely suffer for it. It also makes it difficult to keep track on everyone through check-ups (or stand-ups) which may lead to additional stress and work being lost if the assets produced are not in concert with each other.

Cheers!

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!

Post BGP 2015 – What went wrong (prelude)

Hello all!

As you might have guessed by now the BGP project is over and it was, unfortunately, a failure. This is especially frustrating when considering the fact that it might well have been successful if we had one or two more weeks to complete it, but deadlines are deadlines. I will try to outline what I believe to be the main reasons the project was unsuccessful.

There is quite a lot to cover so I will divide this into several posts. The general outline looks like this:

• Lone programmer (part one)

• Bad/inefficient pipeline & source control (part one)

• Working hours & presence at the workplace (part two)

• Failure to utilize SCRUM & daily stand-up (part two)

I should note that this comes from my perspective as a programmer. I have heard about other problems on the art side of the project but since I did not work on the art in this project I feel that I should avoid bringing that aspect up here. I’ll leave it to the graphical artists that were part of my team to explain that if they so desire.

I should emphasize that this is NOT an accusation against anyone, even though it might seem like I’m pointing fingers at times. I will try to avoid this but I am going to have to talk about other members of my team in order to explain what could have (and should have) been done differently and some of the criticism brought up in this post applies to myself as well.

Part one should be up later today or tomorrow. Part two will hopefully be up not too long after part one.

Cheers!

Lack of updates

Hello all.

I realize that I have not been posting updates for a while now. This is partially due to the fact that I had to deal with being nearly burned out towards the end of may and start of june. I do intend to rectify this however. I am planning to write one or more posts detailing what happened towards the end of the BGP project in the not too distant future.

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!

BGP 2015 – First Week: Learning the Unreal 4 Engine

Hello!

This week I’ve been doing research on the Unreal 4 engine. This is the engine that will be used to make our game, so I’ll need to be as familiar with it as I possibly can, at least the scripting part of it. The game my group is making is a racing game that takes inspiration from F-ZERO, Wipeout and Distance.

I started out learning about blueprints and how they can be used. Blueprints are a visual form of scripting built into the Unreal Engine. It can be combined with normal scripting in C++ and indeed any script you make in code can be made callable in blueprints. I learned about blueprints mainly from tutorials and documentation on https://www.unrealengine.com/. It took a while to get used to but after roughly a days work I started to feel comfortable with how the blueprints worked.

I then moved on to trying to learn how to make functions in C++ scripting that could also be used as nodes in the visual blueprint scripting. It took quite a lot of effort since most tutorials and documentation on the subject, be it official or not, said pretty much the same thing. They stated that all that was needed in order to make a function callable in blueprint was to write UFUNCTION(BlueprintCallable) just before the function declaration.

Like this:

//Fire a Weapon

UFUNCTION(BlueprintCallable, Category=“Weapon”) void Fire();

(example taken from https://docs.unrealengine.com/)

However this did not work for me and I could not figure out why. Eventually, after a lot of searching online and asking fellow students about it, I stumbled upon a post in a forum where a person described the same problem. Turns out that, in some cases at least, you need to restart the Unreal Editor in order for the functions you’ve made blueprintcallable to show up. For some reason, this was NOT in the official documentation.

Once this was sorted out and making functions that were blueprintcallable no longer posed a problem I started making sample projects following tutorials for making racing games as well as downloading and going through sample racing game projects for the Unreal Engine. I was mostly focused on how to code input, either in C++ or blueprints, and what kind of  movement system should be used for our game.

At first I was considering using the vehicle movement that is built into Unreal 4 but it is meant for wheeled vehicles and seems to need to be attached to an object with a model that has four wheels. In the racing game we’re making the vehicles are supposed to be hovering pods powered that are propelled by rockets or jet engines. With some research i found out that there is a type of component in Unreal, called physics thruster, that can be attached to an object to propel it. This worked out somewhat well, I could attach thrusters to an object and bind their activation to player input. However, with this I was not sure how to measure the speed of the object or how to control the acceleration and max velocity. In addition, for each pod vehicle we made we would have to physically place the thrusters and give them a suiting force. If their placement is off, then so will the thrust be. So I looked around some more.

Eventually I discovered that the component for regular character movement has some variables for deceleration and ground friction that I could manipulate in order to make the movement seems less like walking and more like driving. With this I actually can control things like acceleration, max speed etc. Though it still requires some work, this seems to be the movement model we will make use of for our game. The next step will be to start building our first playable.

Cheers!