(you recommend lerping the direction vectors, but surely it makes more sense to slerp?)

Yes, it does.  And if your camera ever makes radical changes RE: which way is up, then absolutely do that.  But for most games with a canonical 'up' direction, I've found that a linear interpolation followed by a normalise usually gives better-feeling results (in my own opinion), just due to the lerp->normalise process giving an implicit non-linear response curve to the camera motion.  And if your 'up' never changes at all (which is true in most 3D games), then it's a lot cheaper to calculate and gives basically the same result anyway.

every previous time I've been sure about this I've still ended up with fucking annoying edge cases.

Yeah, camera code is like that.  It's all trade-offs and edge cases, no matter what you do.  And the system that I covered DOES have bad edge cases -- specifically, if your camera quickly moves between "above the lookat" and "below the lookat", or if it quickly changes which direction is 'up', either of those will lead to bad behaviour.  If you're doing those things, you'll need a slightly more complicated system to handle them.  But that system wouldn't work as well in a more standard 3D platform game-style world. 

(I'm testing the iPad version right now - if you (or anyone else) wants to give the iOS version of the game a try just sign up at http://tflig.ht/uLiBqv and I'll get a build to you )

I've signed up.  Looking forward to being able to see exactly what you're doing, so I can give more focused suggestions!

[The next problem]

(The problem is that the camera position is slerping in a different direction to the camera rotation - works mostly, but not in cases where the direction is changing by ~180º )

I couldn't really figure out what your image was showing, increpare, but I think that this comment tells me everything I need to know about what you're doing wrong.

If I'm interpreting you correctly, then you're making a mistake that's extremely common in games, even mainstream commercial ones (so don't feel bad;  this is really, really tricky stuff to get right!)

The problem is that you're moving your camera around by lerping your camera position and slerping your camera's rotation.  This does not work, mathematically, and cannot ever be made to work reliably, no matter how you try.   So you need to attack the problem in a different way. 

Instead of having a position and an orientation, your camera needs to move around based upon three values:  A position, a "look-at" position, and an "up vector".  (in many/most types of games, the 'look at' point is a point slightly above the player's character)  From these three values you can then construct an orientation each frame.  Constructing a rotation matrix's axes would look something like this:

Code:

vector3 forward = normalise( lookat - position )
vector3 right = crossproduct(forward, up vector)
vector3 up = crossproduct(right,forward)

(that was from memory -- I might have cross products backwards.  Plus, even if I have them backwards, they may still be backwards anyway if you're using a different matrix handedness than I use).  In any case, from the rotation matrix you can construct a quaternion, if your game engine requires that.  Up to you.

So when moving your camera,  you have the camera position, the target position, and the up vector.  Each of these three vectors can safely be lerped from frame to frame (if you lerp the up-vector then you'll want to make sure it gets re-normalised at some stage), and you'll be left with sensible camera movement that will always keep the desired "look at" point visible on screen, no matter what wild moves you're making the camera perform.

The next problem

Now, if you do all this, you'll end up with another (though much smaller) problem, in that if you're moving the camera from (say) in front of the character to behind the character, it will end up passing straight through the character midway through the transition, possibly causing the camera to twist around in a very disorienting way as it passes near or through the 'look at' point.

The way to solve this is not to lerp the camera position.  Instead of that linear interpolation for the camera position, you really want to use either a cylindrical or a spherical interpolation, relative to the look at point.  (cylindrical is better in almost every situation.  Use cylindrical, unless you have a good reason to use spherical)

A cylindrical interpolation basically converts from cartesian coordinates into cylindrical coordinates, and does the interpolation in cylindrical space, then converts back.  The visible effect of this is that as you interpolate from the camera being in front of the character to the camera behind behind the character, the camera will move in a circular path around the character, instead of moving in a straight line over the top of the character.

And now, the math.  In cylindrical space, a point in 3D space is represented by (alpha, d, y) where 'alpha' is the rotation around the y axis, 'd' is the distance from the y axis, and 'y' is the height above zero.  For this conversion and calculation, we treat the 'look at' point as being zero.  So our code looks something like this:

Code:

vector3 delta = lookat - cameraPosition;
float angle = atan2f(delta.z, delta.x);
float d = length(delta);
float newAngle = LerpAngle( t, angle, desiredAngle );
float newD = Lerp( t, d, desiredD );
float newY = Lerp( t, delta.y, desiredY );
vector3 newdelta = vector3( cosf(newAngle) * newD, newY, sinf(newAngle) * newD );
vector3 finalCameraPosition = lookat + newdelta;

(again, this is all off the top of my head.  There may be silly trigonometry errors in it.  But it looks approximately right to me)

When implementing LerpAngle, be sure to handle wrapping around from PI to -PI.  (please feel free to use or adapt my angle class, available here:  C++ source, header;  my implementation is in vsInterpolate, in those files. )

My experience has been that for most 3D games, this cylindrical interpolation gives the best-feeling results.  If your game will ever transition from a camera extremely above the character to extremely below the character, then you might want to consider doing the same angular process for the y component as well, and do it as a spherical interpolation.

If you're in a truly 6DOF game world (Descent, outer-space flight games, etc) then you'll end up needing an even more complicated interpolation to get good behaviour.  And I can go into that if that's the situation you're in in your game.  (But otherwise, it's just needless tricky math, and I have less personal experience with it, so I'll skip that for now.  xD )

Anyhow, I hope that this has been at least somewhat comprehensible and answers the questions you were asking.  This is actually precisely the topic that I've been meaning to cover next in my video series about making games.  But between work and home dev, that video stuff has really been put on indefinite hold for far too long. 

My two unusual coding foibles:

void
MyClass::MemberFunction( arguments... )
{
  // code goes here
}

In function definitions I put the return type on a separate line.  I think that this (a) makes the start of functions stand out more when rapidly scrolling through a source file, and (b) makes the return type stand out more just in general, both of which are useful and good things in my own opinion.  Everyone else thinks that I'm weird for liking this.

class MyClass
{
  int m_myField;
public:
  MyClass();
};

I put private members at the top of the class declaration, with public members at the bottom.  People tell me that this is the wrong thing to do, because people wanting to see how a class works will be looking at the top of the class when they open the header file;  that they shouldn't need to scroll to the bottom to find the publicly accessible parts of the class.  

My response is that for non-trivial classes, the publicly accessible part of the class probably won't be at the top of the source file anyway.  With all the #includes, namespaces, pre-declared classes, and other such things which must come before the class declaration, the start of the class declaration will usually be buried somewhere in the middle of the file, not at the very top.  My assertion is that the choice isn't between "at the top of the file or at the bottom of the file", but is actually between "some random spot in the middle of the file or right at the bottom of the file", and by the mile high menubar rule, the bottom of the file is an infinitely easier place to find than somewhere in the middle.  Why, there's even a button on every keyboard which is used for nothing but going precisely to the bottom of a file, exactly where the interface will always be, when following my approach.  Does your keyboard have a button which will always take you straight to the 'interface' portion of a class when it's located at a random spot in the middle of the file?  I think not!  

Plus, of course, c++ classes were designed to have private members at the top.  That's why 'private' is the default protection level, and you have to add an extra line instructing the compiler that you're doing something different than the language default, if you want to put your public interface at the top.


But I'm in the extreme minority in both these cases.  I don't get to use either of these coding styles at work.  Meanies.  

- a tendency to make certain variables static so I can tweak them in the debugger easily, then forgetting to change them to be something else.

I have this in a prefix file:

#if defined(_DEBUG)
#define vsTuneable static
#else
#define vsTuneable const
#endif

Then in my code I write "vsTuneable float t_blah = 0.1f;" or whatever.  In debug builds I can stop at a breakpoint and modify it to my hearts' delight, while in release builds it gets compiled as a constant, automatically.


#define

So recently, I've been trying to get an internship at a game development company and thinking to myself "Once I'm in one, what can I do to impress the people there with my game designing talent?" Despite mostly being a programmer, a sense of good dame design is necessary for any successful game, so it's something I had to keep in mind.

Speaking as somebody who has been in the industry for over a decade (so old..), I feel the need to step in here, and not answer the question you asked, but to answer the question that you should have asked.


If you get an internship as a programmer at a game development company, the most important thing is to impress them with is your ability to act as part of a team.  This means your ability to take direction, to deliver good quality results on time, to offer ideas when asked (or when otherwise appropriate), and to work well with others. 

If you have the skills for it, then it's also fine to impress them with your coding skills, as long as you can remain within the bounds of their coding standards (see above, about working as part of a team).


If design is an area that interests you, then your programming internship is a fantastic opportunity for you to expand your knowledge and improve your understanding about how you need to think about design in large-scale games which are designed to appeal to a wide audience base.  It really, really isn't an opportunity for you to make powerpoint presentations about game design to people who are more experienced than you and are actually paid to do it, even if you're convinced that your ideas are right, and their ideas are wrong.

As an intern, your best bet to remain in the industry is to be thought of as someone who is pleasant to work with, who can be relied upon to produce results on time and who doesn't cause too many problems.

I'm definitely neither a wannabe or a beginner. For years, I've made tutorials for some people on GMC and answering quite a bit of advanced topics, made a ton of platformers/maze-type games in the past (but still have programming knowledge in other areas), and programmed small games on other languages like C++. I'm intermediate at best.

You need to understand that within the game industry, this experience qualifies you as a newbie.  The standards here are substantially higher than in internet forums.

http://www.youtube.com/watch?v=zX2smM87r14
 

using /2 instead of >> 1

These days, every compiler out there will do that optimisation for you, so don't feel too bad about it. 

It's still generally worth switching your /2.0f into *0.5f, though.

but should people change their game to suit those who don't really understand it?

As before, I think that has to be a personal decision by the author, with both sides being valid choices in different situations for different people.

As you say, the author is going to be held responsible for the message, even if people have misinterpreted his intended message.  I think that it has to be up to each individual author to decide for himself whether he'll be able to clearly project the message that he intends to, and whether he's willing to take the heat from people who misunderstand.

(practical example:  in the above response, I used male pronouns to describe an author.  Some people reading that might assume that I'm implying that all authors are male.  Which, of course, would be a bizarre thing for me to imply.  So I'm willing to take that risk in this reply, for the sake of simpler pronouns, partly because I know that the people in this thread understand that gender really has nothing to do with what I'm actually talking about, and partly because I have this parenthetical lampshading the pronoun choice.  Others would use 'he/she' or '(s)he' or 'they' to guard against that sort of unintended reaction, and that's a perfectly legitimate thing to do, too.)

<>

At the end of the day, what you choose to put in your game becomes the message of your game.  I advocate ignoring what is "realistic" or "statistically accurate";  choose what is artistically right for the game that you're making, in your own opinion.

If you put different genders in your game, and have any mechanical differences between the genders, that difference is going to be part of your game's message.  If you put genders in and don't have differences between the genders, that lack of difference is also going to be part of the message.  Same with races, sexual preferences, etc.  You need to decide which areas you're willing to make a statement on, and which would just distract people from what you wanted them to take from the game.  Keep what you want or need, drop what distracts.

In a game I was working on a few months ago (which actually sounds quite similar to what you're doing), I once noticed the story engine generating a secret incestuous relationship between a father and daughter.  As a result, I added some extra code to prevent it from generating romantic relationships between family members, simply because I didn't want the game's message to be obscured by such a scandalous topic.  It was the right choice, for my game.  I'm sure that others would choose differently, in the same situation in their own games, and that's fine, too.  But as the author, it's your responsibility to decide what what you want your game to say, because it's your name that's going to be attached to that message. 

</ >

Security against their development kits being stolen or otherwise going missing.

They also have policies that the kits aren't allowed to be kept somewhere visible (that is, they need to be under desks or inside cabinets, not sitting on top of desks).  Based on conversations with people in the industry, most companies seem to ignore this policy (and I've personally had to carry one through international customs, explaining what it was to border security agents who were justifiably concerned about the anonymous black box of electronic components), but technically every company signs a contract agreeing to hide the kits before Nintendo will actually sell them to that company.

This seems in line with Nintendo's "locked premises" requirements;  just trying to avoid having the kits go missing due to theft or etc.

Well, if you really think Apple is making a concerted effort to fix these sorts of issues, then it's probably likely due to volume.

I didn't say that at all;  based on the evidence I'd be surprised if they were making any particular effort at the moment.

What I was saying is that I'm not sure what effort they could make to fix things.  Yes, faster response times would help in this situation, but Apple was recently criticised over responding to claims too quickly, during the whole Edge fiasco.  It seems like whichever way they set the policy (fast response vs. slow response), someone will be able to take advantage of the policy to screw indie developers. 

It sucks, but I don't see how anyone can fix the problem of people being bastards and gaming the system to get things they don't deserve.  It's like the various solutions proposed for the piracy problem;  the people doing these things will probably keep doing them no matter how you try to stop them, and in the end, only the honest people are seriously inconvenienced by these attempts. 

I'd be thrilled to hear ideas about practical solutions to this counterfeiting problem, though.  I just don't have any myself, right now, which don't also destroy the iOS App Store for everybody who's being honest. 

I agree that "continued diligence on behalf of the original creators" isn't a tenable position.

But from my point of view, Apple can't verify legal ownership of published materials.  They simply don't have the manpower to do it (no distributor does!), and couldn't afford to do it even if they did have the manpower, without vastly increasing their cut of the sales.  The only way I can see to fix this in a sane manner would be for Apple to somehow verify the identity of the people in its developer program prior to releasing things on the app store, so that legal proceedings could be brought against those people in case of a dispute.

Right now they do this identity verification through:  credit card used to purchase developer program membership, email address associated with developer account, and payment details for app store sales.  But the first and third can be fraudulent (or otherwise shady), and there's no shortage of throw-away anonymous e-mail addresses available on the Internet.  Clearly these have been shown to be ineffective.  But in terms of offering concrete suggestions, I'm not sure what more rigorous and fraud-proof identity verification is available.

Aquin, can you point me at the data you're referencing, supporting these statements?

A:  "These frauds are usually in other countries"
B:  "and difficult to track down."

And anyhow, surely you'd be able to get the information from 'B' from Apple, if you had a legitimate grievance, yes?  It might require a court-ordered subpoena, but you could easily get that by filing a lawsuit against a "John Doe" fraudster, and demonstrating to the court that Apple must have details of their identity.

[EDIT:]

I don't know how payments from sold goods on the App Store currently works, but why can't they just always be delayed by, say, a week. That way, when stuff like this happens, the payment can be withheld until the matter has been resolved... and then paid out to the actual rightsholder of the game. There'll be less risk of these kinds of pirates actually making any money from their wrong-doings then.

Payments from the App Store are delayed.

App Store payments ordinarily occur about a month after the end of the month in which the sales were made, assuming that the total payment-to-developer would be $150 US or more.  (If less than that amount, payment will be delayed until a month after the month where the accrued payment-to-the-developer reaches $150 US)

So forget your "a week" delay, Apple's already delaying the payments by six to eight weeks.  Should be plenty of time for this sort of issue to get sorted out.

EDIT:  If you're a registered iOS developer, you can see Apple's App Store payment policies here.  Just added this link because the information is kind of tricky to find, if you don't know exactly where it is.

[Don't Do It]

Networking is one of my specialties, and with multiple networking-enabled commercial games under my belt, I think I'm qualified to answer this question.  :D

The first thing you have to know about NAT hole-punching is:  Don't Do It (unless you absolutely, absolutely have to)

For the purposes of this competition, it's going to be a much, much better use of your time to simply tell your players that they need to set up their router to forward the port that your game uses.  I know that there was a thread which suggested that all games use a particular port;  if your game just uses that same port number, then you won't have to worry about NAT hole-punching at all, on the assumption that everyone playing the Versus entries will forward that port.

The problem is that NAT hole-punching isn't an "official" thing;  it's a workaround that exploits a common set of behaviours shared between many (but not all) NAT devices.  And while NAT devices are starting to become a little bit more standardised these days (largely thanks to Microsoft's router certification efforts connected with XBox Live), there still isn't a single strategy that works for all routers;  most NAT hole-punching code has a whole bunch of different methods which all get attempted, in the hopes of finding a way to make the two players able to send traffic directly between each other.  This means that it takes a lot of effort, a lot of time, and a lot of testing to get it to work reliably for even a majority of players.  On a commercial networked game, you'll usually have one programmer whose whole job is to handle the NAT hole-punching process.


If you're really interested, I could write an extremely lengthy post on the technicalities of NAT hole-punching (and how and why it works, when it does work), but for the purposes of the Versus competition, I have to strongly urge you not to spend your time on this!  :D

EDIT:  Hey look, I did already write an extremely lengthy post on this subject!  It's over here.