Sprint 4 Demo and Reflection

Sprint 4 Demo and Reflection

Implementation of the wind grid went much smoother than I expected, the grid is simply an array of points and a wind force value, each frame the position of the ship is tracked through those points and the corresponding wind value is applied in a specified direction. Currently the wind force is set to a value that increases as the ship gets further away it's an excellent proof of concept. With a little more work the colour values from a perlin noise image would replace the wind force values and create a much more realistic and dynamic game experience. Currently the array is 2D but would easily update to 3D.

Implementing the 3D perspective is still proving to be a challenge.  I'm going to do another sprint dedicated to it's implementation.

What I would do differently?
Nothing. I'm happy with the use and result of this sprint.

What did I learn?
I'm putting the success of this sprint down to the design. The trouble I had implementing the gravity was likely the result of a lack of good design. With the wind implantation I had a good clear design.

Sprint 4 Planning

It's time to start with the wind model.
This is actually the initial idea behind the project and it was looking like I wasn't going to be able to manage any aspect of it, which would have been a shame.

So I'm starting small. I'm going to get the grid working. This will be a simple grid in which the ships position will be tracked. Each element of the grid will have effects of the wind assigned to it.

It all seems very straight forward so hopefully it will be.

While I'm at it I'm going to try to complete the 3D implementation.

Sprint 3 Demo and Reflection

The investigation has gone better than I hoped. With only a little work I was able to implement a 3d perspective, 3 dimensional gravity and collisions.

I did come across a couple of problems that I'm going to seek advice on.
The Z frame buffer seems to be working in reverse. I've got some experience with depth checkers and I'm sure I've just got something backwards but I can't find it.

I can't figure out how to implement the chase camera. As soon as I have this I can look at implementing a better control system. I'm going to speak with my supervisor about it on Tuesday and go from there.


What I would do differently?
Nothing. I'm happy with the use and result of this sprint.

What did I learn?
A sprint aimed at research and planned experiments can be every but as productive as a sprint dedicated to implantation.

Sprint 3 Planning

Now that I'm getting a grip on this project I'm going to look at expanding into the 3rd dimension.
I'd initially abandoned the idea of doing this project in 3d due to the problems I was having using the framework. Now I'm thinking that I should give it a go.

So sprint 3 is going to be exploratory. I'm going to take a slightly XP approach and write a bunch of experimental throw-away code and see if I can't get a hold on the Z axis. I'll implement what I can and identify the things that are going to cause me trouble. Then speak to my supervisor about it all.

Sprint 2 Demo and Reflection

I'm very proud of myself right now.

This sprint started off well but got very rocky pretty quickly.
I set off to correct by collision handling so the rocks weren't just reversing direction when they collided.
Turns out that the gravity wasn't working anywhere nearly as well as I'd hoped. Some problem with my implementation made managing collisions impossible.
So once again I found myself working on the gravity forces instead of moving on with the project.

Anyway, I've revamped my gravitations, it now less resembles real gravitational forces and more resembles a very simple pursuit model. Basically all of the objects encourage the other objects to chase them at speeds calculated by their mass.
Once that was completed the collision work went relatively smoothly. I say relatively because at the level where the collision responses are being handled I only had access to one of the objects velocity, which made working out the forces pretty challenging. But what I did have was both their masses and positions. So my algorithm assumes that all colliders are moving at least a little bit, it then works out the trajectories of the collision from both object positions and combines, multiplies that by the collidee's mass and applies the result to the collider's speed with a 40% reduction to make it feel a little more real, and controlled.

It's still not perfect but it's much better than it was, I'm hoping that as I get more practice with my vector math I'll be able to more finely tune it.

What I would do differently?

Don't worry so much about getting stuck. Even if you find yourself redoing work, of course it's not ideal, but it's still a step toward completion.

What did I learn?

Smaller bites certainly works. I pretty much chose a single thing and went for it. Now here I am having completed what I wanted to right on schedule.

Sprint 2 Planning

05-03-2012

I’ve had to take a week break from project work to complete other assignments.
Planning for Sprint 2. The plan is:

Collision Detection. Get the collision forces and vectors calculated correctly.
Gravity: turn down the gravity to a slightly more realistic scale. The idea being that the gravitations might be less dramatic but more realistic and more importantly more manageable while ‘playing’ the game.

Triple all my time estimations.

While planning Sprint 2 I estimated that I’d need 13 hours to complete all the tasks I wanted to complete on this sprint. Looking at my current workload I couldn’t see how I could schedule in that many hours. So I had to push from of the tasks to a later sprint.

Sprint 1 demo and draft reflection.

It turns out that multiplying my time estimations by three wasn't even close to enough. but I've finally managed to get a grip on the framework and have created my first demonstration. I present to you... GRAVITY. It's only a 3 second clip because things get pretty crazy pretty quickly.

It's really just a proof of concept because I've not implemented the collision forces correctly, by which I mean at all. The forces just reverse upon collision. That's going to be in another sprint. But gravity works.

For those that might be interested and my own personal remembrance. Each screen object's gravitational pull is calculated using Newton's equation. The distance is measured in 1000m and the objects masses are variants of 100,000 metric tons. The ships mass is 355,000 which is the same as the USS Defiant.

What I would do differently next time?


Consider approaches more carefully.
To start with I approached the gravity all wrong. I initially set each object to gravitate toward everything around it based on it's own mass. I'm not sure why I went about it this way, I suppose I thought that it would just be easier... Anyway after 3 weeks of issues I approached things in a more accurate way and implemented the whole thing again from scratch in about 4 hours. How each object pulls every other object toward it based on universal gravitation.

Smaller bites.
This a fundamental principal of the Scrum approach. If things are taking too long, or are too hard, or if maybe you're just bored of it then the problem is too big. I spent a lot of time trying to understand very complex implementations of iOS and the game framework instead of just focusing on the little things that needed to be done. As soon as I broke the gravitation down to individual lines of code it came very easily.

What did I learn?
When it comes to gravity it's really all about the fine tuning. Pick a scale and stick too it, even if it's just to keep your head straight.

Project Sprint 1

I started my project on Friday. This is after a conversation with my second assessor who suggested that I get the difficult stuff out of the way before my classes become as difficult. It's a good this too because it too me forever to figure out what I was doing.

So I've re evaluating this sprint, everything is getting re-evaluated. I think I'm just going to multiply all my time estimates by three.