I took this course at UBC and it was great. Programming postscript to render 3D animated shapes was mind-blowing. Especially cool was that you needed to build everything from scratch
AI programmer here...generally "bots" are just AI that is intended to take the place of a player (typically in a versus setting and not a co-op setting).
If anything bots are tougher to make then "normal" AI since their value is measured by their performance against humans. Also the less you cheat (perfect knowledge of the other players, perfect aim, etc) the better your bot. Having a non-cheating bot beat a human is a major achievement.
The bots for a strategy game like StarCraft is fundamentally different than the bot for an FPS. They use completely different techniques and it's much harder to cheat in strategy game (though ignoring the fog of war is the most egregious). Strategy game AI is more akin to chess AI - lots of search (minimax and stuff). It's a whole field onto itself and you can only learn by studying the AI for that type of particular game.
FPS bots (like counter strike) are much closer to traditional game AI (shooters and such). Books on "Game AI" are a good place to start. Basically the two major problems is where should I go (evaluating cover, analyzing line of sight, estimating where enemies are and trying to pick a good place to stand) and how to I get there (pathfinding and pathfollowing). What you do when you get there is generally pretty straightforward (shooting at the appropriate guy). If you have a cover system you need to be able to tell them how to use cover and this involves a lot of animation (syncing my animations and position up to the cover in the world). But in an FPS this is usually just a question of crouching or not.
The big difference for FPS bots (versus single player enemy AI) is that bots need to choose between conflicting goals (should I go get ammo, should I go get health, should I attack the enemy). If you have a strict hierarchy of behaviours your bots won't be competitive (enter fuzzy logic systems, utility theory and the like - normal behaviour trees won't cut it).
Too bad it doesn't matter at all what you personally recognize. I happen to agree with you. And it does suck that reason has anything to do with this stuff. It's about money and control. This is just another example of a few people or corporate entities vacuuming up all the resources of the world. In this case they are vacuuming up raw ideas and the ability for individuals to profit from those ideas. They do this because they can. They have power and they use that power to change policy to allow them to do this. It's that simple. And it will only get "better" if it suits them. And I don't see it suiting them. Vive la revolution!
There's one reason why open plan will always rule over individual offices or 3-4 person team rooms: you can fit more people into open plans. If square footage matters to your bottom line (ie your office isn't out in the warehouse district) then you can get more employees per sq ft. Bitch all you want, but it ain't gonna change.
Exactly. Saying that this is just the way it is is ludicrous. They could under sufficient pressure change the wording so that they aren't assuming ownership or unlimited use and that it is something more akin to fair use.
There's been a couple of these types of articles on here lately. All of them break down into "Programming is broken because I can't just say to a computer what I want and have it created for me". We have to specify the process gets something done because it takes a hell of a lot of smarts to do this. Even things that seem very easy and straightforward to say out loud are filled with unknowns, assumptions and inconsistencies. Maybe all these "programmers" can stop whining about how programming is broken when we've created an AI that will understand what they want and just write the program for them. And as for constraint satisfaction programming - if you've ever actually programmed in prolog you'd realize that properly defining the problem such that you get a proper answer back is a hell of a lot of work. Prolog has it's place, but if it saved a huge amount of work and was easy to use people would be using it more often.
What a dolt. It's possible to tell the compiler that two pointers aren't aliases: the "restrict" keyword. Unless I'm mistaken that is really his sole argument against "pointer-based languages".
If he can't say that it's easy to measure whether someone is 10x more productive than the average programmer then how can he say they are 10x more effective?
Also I work at 200 person game company and there is no programmer that even performs close to that level. Maybe 2 to 3x the average for absolutely exceptional programmers. But your average would have to be pretty fucking crappy to get anything more than that (and even very talented programmers aren't more than 2x the average).
Regarding the question about whether it's fair to call this an AI library...well it's kind of a valid question. But really this is game AI which is isn't trying to be Artificial Intelligence, it's just the subject of making game agents perform behaviours and look intelligent - or even just functional. But is your question really even an important question? Much of classical AI can just be reduced to search (which is why prolog is so popular in university AI courses). Is search AI? Is it any more AI than putting together control flow statements? There is a lot of stuff that can happen in those condition and behaviour nodes. And yes in trivial examples the control flow is fixed, but the "learning" is done by hand by the coder/designer (is it any more "AI" to have it done by a evolutionary algorithms?). And more advanced versions of behaviour trees can incorporate much more sophisticated selectors than just "pick the first that works".
What a ridiculous argument (something of a given intelligence can not possibly create something more intelligent)! It's kind of like saying no one who can only run at 15 miles per hour could ever create something that can go faster than 15 miles per hour.
We get royalty money in the games industry. Of course it depends on the project deal, but often once the game has sold a certain number of units royalty checks start coming in. For very successful games these checks can be quite large.
It's not that hard parsing template compiler errors (though I am looking forward to better errors in C++0x). Are you saying this is a good reason not to use templates at all? With a little practice they start to make sense. I'm sure for novice programmers the first time they see 500+ error messages stemming from a missed semi colon or curly brace (in regular code) it can be pretty bewildering too, but just like with template error messages you just ignore virtually all of it.