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.
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.
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.
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.