Git is awesome

We've made some good progress over the last week.  Movement code is properly working now, the player can pick up and throw objects, and we have other fancy mechanics like a ground.

What we're going to be working towards before Tuesday is to bring all of that together with collision detection and destruction.  Objects will react to each other, and when they collide, they'll have sophisticated conversations about what their mass and velocity is and which one of them should explode.

All in all, I'm really happy with where we are.  The team seems to be working together really well, and we've started to get past the awkward stage where nobody wants to touch other people's code, so over the past week a lot of progress has been made.  I think we're in a good position.

The point of this post though is to give a word of advice.  When we started this project, we collectively decided that since not all of us knew how to use Git repositories, we'd just coordinate over Google Drive.  This was a really big mistake; right now we're manually merging files, we have a sign-out sheet so we don't accidentally undo each others work, and we're maintaining manual backups of all of our versions - all of this is stuff that Git would be doing for us automatically.
I speak for pretty much everyone on our team when I say that managing group repositories on Google Drive is a nightmare.  Learning Git is really worth it, even if it seems inconvenient in the short run.

Parallax effects for game objects

This week I worked more on physics and throwing objects.  While they're great for the player, the problem I've run into with fake physics is that the systems rarely play nice together - because the systems aren't following real rules, the rules they do have often contradict each other.

I wanted to fix some of this, so I redid the systems to be more internally consistent.  The rope winch has its own acceleration system, momentum system, velocity, and most importantly, wind resistance.

Wind resistance is important because it's normally left out of physics simulations with Box2D, but it adds a level of intuitiveness to ours.  If you throw a ball out of a moving car, theoretically you could get it to bounce along side, but you never expect it to - you want it to trail off behind you.   By including wind resistance as a variable (based off of what the velocity of the helicopter is), we can get semi-realistic trailing of the rope without directly effecting the rope's underlying velocity.

I've also been playing around with parallax effects and how that effects objects l.  Originally, we had distinct layers that were positioned alongside the camera.  However, we didn't want to nest objects that would be interacting with the game world in a separate clip.  The solution to that problem ended up being adding them to a separate blank tracker during runtime.  That way, all of our references still worked, but we could also drag around a layer and treat it like a single object.

Flash Scaling and Converting Coordinate Systems.

This week I'm going to be moving back from architecture and camera development to the physics systems again.  I'm working over a way to use air resistance to help make the game's logic a bit more internally consistent.

In the meantime, you may recall that I talked about Flash coordinate systems very briefly last week.  The tricky thing when doing conversions is figuring out just how little Flash cares about what's done to its parent clip.  I want to reiterate that principle this week and give some specific instances where that's likely to bite you.

For example, if you resize a movie clip in Flash, the internal coordinate system of that clip stays exactly the same.  That means if you're doing conversions manually, you need to multiply all of your final values by the scale. 
Rotation is another point where Flash doesn't care - a rotated movie clip will internally have no change in it's coordinate system whatsoever.  This can, again, lead to problems if you rotate an object with a lot of children by 90 degrees - when referencing that object's children, your x axis and y axis will be switched, because the children don't know that they've been rotated.

The best way I know of to think about this stuff is to imagine a parent clip as a lens for its children.  The parent clip can be manipulated in a number of ways, and that manipulation will show itself in the children.  But the children themselves are never manipulated.  They just look like they have been, because they're being viewed through the lens of the parent clip.

This is another reason why localToGlobal is so ridiculously useful.  It worries about that stuff for you.  I can't emphasize enough how much time you can save by using those functions instead of doing the math yourself.

Camera Controls in Flash

I was going to work more on the physics system, but we ran into some issues with our camera class, so I took some time to figure that out.  There's a little bit left to do, but it seems to be working well so far.  The big problem with Flash cameras is that coordinate systems become overly complicated.  Flash uses local coordinate systems, so objects embedded within other objects reset what their 0,0 position is.

There are a couple of ways to fix this.

point = clip.localToGlobal(point); //This code will allow you to convert a local coordinate system to the actual position on screen.

localToGlobal has some issues in that it always defaults to the top layer.  So if you have an object nested down three layers, and you want it's position on the first layer, you run into issues.

If you can, you want all of your objects to be working on the same layer, that way you don't have to deal with that huge mess.

We have a single camera class that doubles as our world class.  All of the code for the game acts in this movie clip, so we don't need to worry about conversions.  When we do need to worry about conversions, I reference back to the world class so that, again, all of our code is running in the same coordinate system and we don't need to worry about too much math.  I'm not going to go into too much detail, but I use both localToGlobal and then the reverse method globalToLocal to get the coordinates.  Because all of the game objects have references to the world class, we can use that as an interpreter for everyone's different positions.  All any one individual object needs to worry about is letting the world class know where it is, and making sure it goes through the world class whenever it references any other object's position.

In terms of the camera (world) class itself, we have fairly standard controls.  The camera can grab any movieClip and center itself on that clip.  Internally, it re-centers every update loop.  We can also set scale, etc... although most of that code will probably be written directly within the game's core update loop, rather than in a separate method.

The camera itself doesn't use localToGlobal.  It manually calculates the changes in coordinate systems.  The problem is that localToGlobal changes as the camera adjusts itself.  Doing the manual conversions provides a lot more consistency.

There's still a lot to do - looping the world around, deciding how objects are updated, etc... still needs to be coded.  But we have a good base to do that now.

Finally, I'm experimenting with parallax effects.  I don't have everything up and running yet, but what the camera should be able to do eventually is grab different layers (background, foreground) and adjust them accordingly.  From what I've been seeing with my experiments, having objects and their backgrounds move at the exact same pace is somewhat disorienting, so I'm pretty keen on trying to get that working before too long.