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.

Mario Galaxy and Lost Winds have gorgeous depth of field and they are on the Wii, which as I understand has no shaders.

Just a quick clarification.

While it's true that the Wii doesn't have shaders like those on PCs and other consoles, it does have a system for customising the behaviour of renders (which I won't go into any detail about, since I'm under NDAs about it).  Suffice to say that you can get many of the same effects through the Wii's system that you can get under full shaders.

There was something similar on the PS2, incidentally.  You could do a lot of customisation of rendering to achieve effects similar to primitive shaders.  Plus, on the PS2 you could do tricks which were like the geometry shaders which have only very recently become possible in DirectX and OpenGL.

So don't judge graphic effects based upon what can be done on the Wii or other consoles;  they're really in a completely different graphic world than PC-style systems;  some things are much easier than on the PC-style systems, some things are much easier on some consoles.  And without actually working on the particular console (and thus becoming covered by a nondisclosure agreement which prevents you from telling anyone else), you won't really know what's possible and what's not.

I really need to find something to absorb some of that sound..

If you have bad acoustics in your room, make sure your microphone is dynamic (not condenser) and has a cardioid pattern. Or even better, a supercardioid pattern. That will prevent a lot of unwanted noise from going into your recording. An example microphone is the Shure SM58 or Beta 58.

Yeah, mine is a condenser microphone, though it does have a cardioid pattern. 

Anyhow, I don't have a problem with noise;  I can get the room positively silent.  It's just that I end up with a hint of echo bouncing from the mostly-bare walls.

My trouble is that I don't have a room with good acoustics.. have everything else sorted out, but everything sounds vaguely echo-ey because of nasty audio bouncing off all the walls.. 

I really need to find something to absorb some of that sound..

Battlezone?

Yep! 

1. Curse you, missile; now I'll never be a vulcanologist.

1.  Press your face to the viewfinder to play, and try not to think about the personal hygiene of the last guy who played.

Uhhhh... Sea Wolf?

Hey wow, I hadn't heard of that game before!  No, but you're thinking in approximately the right era.  Couple years later.  But it's exactly the right sort of viewfinder!    :D

Or alpha testing if the sprites use rough pixels?

Side-note:  alpha testing is absurdly slow on the iPhone/iPad.  You want to use it absolutely as little as possible on those platforms.

But putting the transparency information straight into the alpha channel of your texture is what you want to do;  OpenGL's blend modes are really designed to work that way. 

1. Curse you, missile; now I'll never be a vulcanologist.

2. No, you're gonna try something dangerous, now.  Sorry, pal.

3. Dumbo makes me sad.

Further hints:

1.  Press your face to the viewfinder to play, and try not to think about the personal hygiene of the last guy who played.

2.  Which do you want to eat; the red goo, the green goo, or the blue goo?

3.  Getting here is half the fun.

hmm well it crashes when both my server/client apps sending a udp packet to each other on one port (im testing on one computer)

Apologies, Eva, I should totally have thought of that common situation!

Yes, you ordinarily can't have two programs using the same network port on one computer.

For testing on a single computer, I'll usually have a program try to bind its socket to port 'n', and then if that fails, have it instead try to bind to port 'n+1'.  And then attempt to send its packets to whichever port it's not using, itself.  That way I don't even have to think about issues with sockets;  I can just run two instances of my program and they'll figure it all out by themselves.

There's no reason why you need multiple ports for a LAN game.

Unless you're talking about supporting multiple players on a LAN who are also playing against other players on the Internet, via a NAT device.  In which case, yeah, different ports for the different players is kind of an awkward workaround which will allow it to work for some NAT devices.

But in general, you can either do LAN play or Internet play, not both at the same time, just due to the complexities of NAT.

(There are ways to support LAN+Internet for many (though not all) NAT devices.  If you really want the gory details about how to do it, contact me directly.  I've already polluted one thread with lengthy and inappropriate details about how to do these probably-unnecessary-for-this-competition things;  I don't want to do it again!  :D )

 

I like the bold section

I should have put it up at the top of my post, instead of buried in the middle!  XD

[But on the other hand, if you're just making a once-off game for this competition and don't plan to have any cross-platform support in it, then absolutely don't worry about any of this, and just do whatever's fastest and easiest so you can focus on making your game awesome by the deadline. :D]

This is an extremely pedantic point, and should probably only be read by people who are interested in networking "best practices" on the Internet, beyond the scope of this competition.  For all others, please skip down and just read the bolded section. 
 

Big-endian is the defined network format (and has been for decades).  For the general sanity of network interoperability programmers everywhere, all numbers should always be converted into big-endian format before being sent over a network, and then be converted back into the recipient's native format upon being received.

Yes, you can ignore that guidance and decide that for your own game's protocol, you're going to send everything in little-endian.  Just be aware that the rest of the Internet and all related standards go the other direction.

And certainly there are still a lot of big-endian machines out there.  Older Macs, lots of Linux/Unix boxes, XBox 360s, PS3s, etc.  If you're planning to continue doing network stuff, it's important to know how to interoperate with the network properly, and converting your data into the standard network byte order for transmission over the wire is an important part of that.

But on the other hand, if you're just making a once-off game for this competition and don't plan to have any cross-platform support in it, then absolutely don't worry about any of this, and just do whatever's fastest and easiest so you can focus on making your game awesome by the deadline.  :D


But if you really do want to know about how to handle floats on the Internet, between arbitrary computers which may have different endianness...  the floating point format is a standard that every modern computer uses (ignoring the byte ordering issue).  In order to transmit a float over the network according to the standards, you have to reorder the bytes into network byte order (big-endian), and then reorder them back again upon receipt, exactly the same as you do with integers.  However, there's a gotcha;  a byte-swapped floating point value can't legally be stored in a floating point register on the CPU.  The float will typically be invalidated (ie: written over with some form of NaN) if the CPU ever notices it in a register with its bytes swapped around.  So in order to byte-swap a float, you need to use a trick to keep the computer from viewing it as a float while it's byte-swapped. 

In C, here's how I'd do it:

float myValue = 2.0f;
uint32_t myPretendIntegerValue = *(uint32_t*)&myValue;
uint32_t myByteSwappedValueForSending = htonl(*myPretendIntegerValue);

Then to convert back on the other side:

uint32_t *myPretendIntegerValue;
uint32_t myReceivedByteSwappedValue = <whatever I received>;
myPretendIntegerValue = ntohl(myReceivedByteSwappedValue);
float myValue = *(float*)&myPretendIntegerValue;

At this point, 'myValue' now contains the transmitted floating point value.  At all times when the float was byte-swapped, its bytes were being stored inside a 32-bit integer, which kept it from ever being loaded into a float register and thereby becoming invalidated.  Yay, complicated!  But you'll find that there are no standard network functions for manipulating floats, so this is pretty much the best I've been able to come up with..

I agree that OpenGL 1.4 is enough for most 2D usage (and even basic 3D usage).  My comment was based upon information provided on the OpenGL web site.  Specifically this quote:

Without drivers, you will default to a software version of OpenGL 1.1 (on Win98, ME, and 2000), a Direct3D wrapper that supports OpenGL 1.1 (WinXP), or a Direct3D wrapper that supports OpenGL 1.1 (Windows Vista and Windows 7). None of these options are particularly fast, so installing drivers is always a good idea.

This may just be a typo on their part;  seems odd to have listed OpenGL 1.1 support twice that way, and for all I know, they actually meant 1.4.

But I want to add that I agree with Ludophonic; if DirectX is working for you now and you've no desire to go cross-platform, then there's absolutely no reason to change.

It's worth pointing out that Windows still only ships with support for the OpenGL v1.1 specifications, which are pretty absurdly ancient (the current version is 4.1).  Installing a recent 3D video card driver will generally upgrade the system's OpenGL support to somewhere around the v3 to v4 region.  

This means that under Windows, you have the same issue with OpenGL that you currently do with DirectX;  if your user hasn't already installed DirectX/recent video drivers (respectively), then they won't have the things your game needs, and will need to go download some extra stuff from the web in order to play your game.

Personally, I use OpenGL partly because I like the API (I die a little every time I have to deal with Systems Hungarian Notation), but mostly because I like not having my games be locked as Windows-only.  But it's quite reasonable to want to learn both APIs, or to simply prefer DirectX for whatever reasons.

So it's really up to you.  Do what makes you happy, and don't pay too much attention to advice from platform zealots on internet forums.  (including me).