Personally, I got turned off by the fact that as god games became more complex, I seemed to spend more and more time doing really boring micromanagement tasks.
Black and White in particular had the odd situation where I was playing as a super powerful god, but I seemed to spend all my time being a child minder to stupid minions. Now Godus combines similar tedious micro management with farmville-esque clicking-on-stuff-to-collect-it.
So I ended up making a god game which focuses on global war and destructive acts-of-god because I think the key thing about god games is the wielding of power, not worrying about minutiae.
Why worry about $200, the amount of time you've invested in getting your game this far is worth much more than $200.
Will you make the $200 back? Not sure, the game looks pretty enough to, but plenty of games don't make anything and there's a very good chance your game will be the same.
Will it be worth it from a learning point of view? Yes, go for it! Plus, it's a big personal achievement and it's quite a buzz releasing your own game on the app store, even if you do lose money on it.
Hopefully you'll have a couple of proper titles on your CV by the time you look for a new job, and this can sit as a single bullet point in an 'Other TItles' section.
Just don't exaggerate it on your CV, the chances are reasonable that the guy who will interview you will know someone who was on that game team for the entire project, and you really don't want to be caught out in a lie.
I think your problem is identical to voxelising the frustum shape, so perhaps you could direct your google searches in that direction.
It's not something I know anything about really. Maybe picking a point that you know is inside the frustum and then flood-filling the voxel grid would be an OK approach (I'm sure it's far from optimal though!).
Another thing to think about is whether you want to use a 'push' or a 'pull' approach to loading resources.
The pull approach is perhaps more natural, you have a bunch of resources set out into a logical (to a human) folder structure (possibly in some sort of zip-esque archive format), then your game code requests the assets it needs in some arbitrary order and they get loaded. Sometimes when you're loading a model, it might contain dependencies on some texture or sound, so you fire off loads for them too.
The problem with the pull approach is that you're seeking all over the place. Which is fine for solid state storage (SSD, cartridges, mobile) is OK for hard disk drives, but is a total nightmare for DVD/Blu-Ray, etc, as the seek costs can be huge.
The push model is an approach where you create a single file for a collection of stuff that will get loaded together. So if your game is level based and non-streaming, your tools might construct a single level file containing all the appropriate models, sounds and textures. The game code will request to load the level file, and the load process will push each of the resources it comes across into the right subsystem.
I guess with the current crop of platforms, and the fact that games stream so much dynamically, the push vs pull choice is less important, and it's always possible to make the pull model work OK by carefully laying out resources on the storage media, but I think the push approach is the better one if you're planning out a system from scratch.
Generally, the fastest collision algorithms are for simple geometric shapes (spheres, ellipses, orientated bounding boxes, capsules, cylinders, etc), if you really need arbitrary geometry, then it's a lot faster to implement collision for convex hulls, finally and slowest, if necessary you might need to collide against polygon soup.
So, your question is pretty broad. You need to work out what you can get away with for your use case. You might conclude that your characters are well represented by capsules and your environment is a polygon soup, then you'll need some sort of hierarchical representation of your environment to collect relevant triangles, and you'd need to google triangle vs capsule collision detection to find out how that's done.
I totally get where the OP is coming from. I've played FTL on PC and cheated occasionally to backup saves. Now I'm playing on iOS where it's harder to cheat - it's still totally possible, but there's enough friction in the way of cheating that I don't bother. The game is a very different experience because the stakes are much higher when permadeath can't be circumvented.
IMO, your option #3 is the best. By having a save file and a corresponding registry entry (with a timestamp or hash or something), it's still easy for someone to cheat/transfer the progress, but I think the extra step of having to modify the registry adds just enough friction to the cheating process that I think that large numbers of people wouldn't bother.
In a theme park management game (might have been 'Theme Park') there was a negotiation mini-game for agreeing wages/supplier prices where you gradually reach out to shake each others hands. Give too much and you pay over the odds, give too little and the deal breaks down entirely.
You could include something similar for your hiring process perhaps.
It is a pretty mature, well documented piece of software so I don't think you should reject it completely just because there's no active support/development, but it's probably something to factor into your decision making.
I'm using it in my game, but only for my local multiplayer. For internet multiplayer I was planning to go with Raknet (and have working code for it), but ended up going with gamecenter instead. Although that decision was mainly to avoid the burden of paying for and running matchmaking facilities.
This is obviously not real life evidence of anything whatsoever, but someone at Apple thinks that a bad network has 10% packet loss. Two machines both on a bad connection would have 20% packet loss on their communication (well 19%, I suppose).
I think if you can deliver a reasonable networked game experience under that sort of packet loss, then you're doing fine.
If you have a large old-ish codebase you could be looking at a significant amount of work supporting 64 bit, so don't expect it to be a tickbox. Plus you may have headaches if third party libraries you use don't work in 64-bit.
Regarding the iOS8 SDK mentioned in the OP. It's a bit confusing, but when Apple talk about you using the iOS 8 SDK, it means that you must compile with up to date xcode. You can still compile with the iOS8 SDK but make it target iOS6 as its base SDK, so you don't necessarily need to replace your iPod4 because of the iOS8 SDK requirement. However, you do need to replace it so you can test your 64-bit compatibility.
You could use 'additional programming' to describe the people who only did a little bit.
I'd say that you could get away with calling yourselves senior programmers with 5-6 years. It is a little bit of a stretch but hardly a complete piss-take. After all, you could be technical directors, heads of programming, CTOs or lead programmers, so describing yourselves just as senior programmers is showing some restraint.