I'd recommend NOT Bezier curves. 
Bezier curves do not go through the control points, as in your illustration, making them useless for certain applications.
Polynomial or Spline Interpolation is probably what you are looking for (Probably spline as Jimmy said).

You are right.  I was confused about what strongly typed meant. 
What I meant was:

Code:

var a; //No type here

Is allowed.  Which I thought strongly typed didn't allow.  But it does.  Now I know.

Ni No Kuni, the studio ghibli game:
"The game will also include a book that is supposed to represent the magic book from the game and is required to play the game. In it players can find a bestiary, short stories that offer game hints and other info that the game will refer to."

I like the requiring studying a book inorder to progress, not a strategy guide, but a book that adds to the game, part of the gameplay.

See also: just about every adventure game from the '80's and '90's.

The MGS games have a ton of quirky gameplay mechanics.  MGS 1 has you check the back of the jewel-case, 3 has the waiting until a boss dies, the giving a boss food poisoning so you can shoot him, etc, 4 has a dream sequence that plays exactly like an earlier game.

Gotta hand it to Kojima, he's good at thinking up quirky ideas.  Mostly he just uses them once and moves on, but occasionally (Boktai) he makes an entire game around the idea.

I think action script is very easy to pick up.
Here are some code examples:

Code:

//C#
double Foo(double abc){

   return abc*abc;
}

//AS3
function Foo(abc:Number):Number {
   return abc*abc;
}

It too is an object oriented language,but it isn't strongly typed and it doesn't support generics.

You should get the hang of it pretty quickly.

The problem that XNA has (had?  someone else can answer better) is the platform dependence, i.e. Windows and XBLIG only.  And it requires a fair amount of stuff to be packaged up or installed for other Windows users.

I'm a big proponent of Flash as I think it is very easy to get up and running with it.  The Flixel/FlashPunk debate has been handled elsewhere, but it's mostly a matter of personal taste.  Right now, I'd recommend using nd2d or nd3d (depending on your game type) and some sort of physics engine (box2d if necessary, your own simple system if not) to someone starting out with Flash.

Some obvious things to consider before diving in to a paper:
 - Does it come with evidence that it actually works?  Ideally in the form of a demo I can play with and stress test myself.

It's funny that you bring this up.  I have a friend getting a PHD in applied math right now, and he is extremely frustrated by the lack of demos/source code accompanying papers.  He believes (and rightly so, in my opinion) that papers that describe algorithms should come with source code (that actually compiles to some sort of useful demo) to demonstrate their worth.

Well, as you said, most roguelikes make sure that there is a resource that limits the player that isn't available in infinite amounts. 
Here are some options:
1) The church will heal you, only if your deity is sufficiently happy.  Your deity is only happy if you smite the evil-doers.  e.g. You can only heal if you have killed a sufficient number of monsters.  This might be too hard on the player, but it removes the kill a monster, go heal, repeat.
2) The church can heal your body, but does nothing to sate your hunger.  Standard RL procedure.
3) Remove the church.  The player can pray to heal, but this takes time, so they can't do it in the middle of battle.  Also the 1 & 2 can modify this.
4) Churches aren't an infinite resource.  You have to pay, or they are a one-shot use, or something.

It seems to me "flash is bloated and slow" and "there are currently no superior web technology alternatives to flash" are not contradictory statements

They certainly aren't, but I think that "flash is bloated and slow" is a bit unfair. 1) I don't think Flash is bloated and 2)Flash is typically fast enough (well, pre F11:so long as you can get by blitting).  This isn't to say Flash is fast.  It isn't.  And there is a lot that Adobe could do to make it faster, and yet they don't. 

Edit -- Sorry, I was drunk and mopey when I wrote this.  Don't need to throw a pity party for myself.  

Well, given that he never stated that it wasn't a floating point problem, I'm going to go with no,

Hue is returned as an integer. ie, this is not a floating point problem.

Well, there is no such thing as an integer in GML, to my knowledge, but whatever.

@Fallsburg:  That looks rather messy as you've converted it to a floating point problem.

Your function does allow hue to be outside the domain 0-240, but this is beyond the scope of the problem.

What could be done is to add tests at the start of the function to see if the two input hues are in the correct domain, and return an error if they are not. But it's up to Theophilus how the function is defined, and whether it needs to be able to handle inputs outside of 0-240.

If it's a blackbox function to be added to a code library, then it would matter.

Well, given that he never stated that it wasn't a floating point problem, I'm going to go with no, I didn't convert to a floating point problem.   And it isn't messy.  It's mathematically sound, not a cluster-cuss of conditionals.

[Rule 34: Never use inequalities with bearings!!!]

I think it's better to understand the problem rather than just be given the answer. So that is what I shall attempt to do...

Rule 34: Never use inequalities with bearings!!!

What you have to do is calculate the angle between two bearings. If you are familiar with modular arithmetic you will know that angles can be measured clockwise or anticlockwise from one bearing to another, and the angle between is generally considered to be the smaller of these two measurements. Two angles are said to be congruent if they differ by an integer multiple of 2*pi (or 240 in your case), and this is what you must add/subtract to put angles into a standard range.

In your situation, you want the standard range to be (-120, 120]. Veracity's formula above expresses this is a compact way:

(diff > 120) * -240 --> subtracts 240 if the angle > 120 (above the upper end of the standard range)

(diff < -120) * 240 --> adds 240 if the angle < -120 (below the lower end of the standard range)

This still doesn't solve the problem.  You've only shifted the edge from 240,0 to 120,-120.  


The only thing that I can assure will give you the correct answer is the following:

Code:

compare_hue(col1, col2, range){
//ASSUMING MAX RANGE OF 240
max_range = 240
col1_0 = cos(col1*2*pi/max_range)
col1_1 = sin(col1*2*pi/max_range)

col2_0 = cos(col2*2*pi/max_range)
col2_1 = sin(col2*2*pi/max_range)

dot = col1_0*col2_0 + col1_1*col2_1
ang = acos(dot)*max_range/(2*pi)

return ang < range
}

Obviously this is inefficient, but off the top of my head it is the only thing I can verify will always be right, isn't a mess of conditionals, and makes perfect mathematics sense.

What I did was, convert your "angle" (color) to vectors, and then found the "angle" between the vectors.  See http://www.euclideanspace.com/maths/algebra/vectors/angleBetween/index.htm for more info.

Well, I can think of an obvious stupid way to do this, but I'd be interested in seeing if someone (st33d, looking your way) has a better idea.

So, something like this would work:

Code:

var bd:BitmapData = (new EmbeddedImage).bitmapData;
var height:Number = bd.height;
var width:Number = bd.width;
var replacementColor:uint = 0x0;  // Black
for (var jj:Number = 0; jj < height; jj++){
    for (var ii:Number = 0; ii < width; ii++){
         if (bd.getPixel(ii,jj) == 0xFFFFFF){ //WHITE
             bd.setPixel(ii,jjreplacementColor);
         }
    }
}

This will replace all of the white pixels (although I'd pick a less used color, like the standard hot pink) with black.

This will be slow and inefficient, but so long as you only need to do it at the beginning of your game and the sprites aren't huge, that won't be a huge problem.

If you need to combine together multiple sprites to make one larger sprite, you can use bitmapData.copyPixels  (see the AS3 documentation for more info).

EDIT:
larsiusprime makes a good point about pixelbender.  It will be much faster than the getPixel/setPixel way of doing things.  I still wouldn't recommend doing it every frame or some such, but it would be more than good enough to do it and then store the results.

RE: Deviations

How many iterations are you doing per physics step?  To my knowledge, box2d uses Euler integration, which will lead to differences (see wikipedia for a nice graphic) as mentioned by Jasmine.  The higher the number of iterations the closer the simulation (box2d) will be to reality (the equation). 

I think that doing the parabola should be enough.  If you must go further, it should be like Peggle where the arc is shown for a small portion after the first contact. 
If the latter is the case, then you are going to have to use Box2d and simulate it ahead of time (unless the collisions all fall under easy rules [i.e. circle colliding with rectangle]).

@mikejkelley:

Sent you a PM, didn't realize you'd posted here first. I'd post it for everyone's benefit, but I forgot to save a copy in my outbox, and.... I'm lazy

If anyone else is interested in academia, lemme know and I'll try to retype it.

I'd be interested if it wouldn't be too much trouble.

Today, I learned that Flash 11 wants me to kill myself.
Trying to save a file via FileReference when in full screen mode causes Flash to lock up. The workaround is to go to normal mode before saving a file; However, going from full screen mode to normal mode causes Context3d to drop from the GPU, crashing the graphics.
BUT, I learned that it only drops from the GPU IFF you set Flash to full screen mode BEFORE you set up the Context3d. If you set Flash to full screen mode after, then you can go back and forth between full screen and normal screen modes.

So, I'm happy that I found a horrible/hacky solution, but I'm also extremely pissed off that I had to find a horrible/hacky solution, just so a user can save a level while in full screen mode.

Re: Upgrading: I think the best option (for the user) would be to have the game check for updates when they load it up.  They can then choose to update or not (or do it seamlessly, without them realizing if possible).  That way you wouldn't have to worry about notifying everyone, you would just notify those people who were still playing your game.

It's funny that everyone needs a profit-sharing model in order to get up and running,...

You hit the nail on the head here.  Everyone needs a profit-sharing model to get up and running. 

BUT most of the things that people do at the "get up and running" stage are complete failures, hence why those who are experienced think it is dodgy (i.e. they want to get paid, and know that profit-sharing won't lead to that).

A possibly simple solution would be adding random noise to your target position for each time step that the missiles update.

Not a bad idea, but you might want to make the noise correlated, e.g. if the random draw on frame 1 was -5, it might look bad if the next random draw was +10.  So, perhaps you do a random draw and then use that as the mean and/or median of the next random draw.  This way, you wouldn't get rapidly varying noise.