text:
What standards should designers/artists follow when giving UI assets to coders?
How do you or your company require designers to deliver their assets to coders?  Do they deliver a PSD?  A series of 24-bit PNGs?
If you are a coder, what would you include in a best-practice guideline to designers?  If you are a designer, what questions would you like to see answered in such a document?
Here are some ideas:

Generally:

include designs for mouse-over and mouse-down states for all
buttons and other interactive elements, as well as the normal state.
for toggle buttons, this can also include different states for
both selected and unselected modes, for 6 states total: normal,
over, down.
in drop-downs, lists, etc, please design a selected and unselected
state for each item, if appropriate, especially where the content
varies.
Flash is strictly an sRGB colorspace.  If creating assets for
Flash, make sure that your deliverables look how you expect it in
sRGB.

If delivering assets as a PSD, please:

label all layers clearly.
make sure that the dimensions of your document exactly match the
dimensions of the application

What else would you include in a Visual Asset Delivery Best Practices document?

Don't ever, ever, ever use PSDs. Not even if all you use is Photoshop. To quote Jeff Schewe: TIFF = Good, PSD = Bad (read his whole rant if you want to know details)

@Martin Sojka: I don't understand why TIFF should be any better than PSD. The PSD specification is available as well and several third party developers have implemented it. Also I just tried to open a (layered) PSD and the same file as TIFF in GIMP. Opening the PSD preserved all layers, but lost some of the special PSD layers (effects) while the TIFF just opens as a flat file (no layers are parsed at all).

@bummzack Mostly because TIFF is open (and always was), extensible, free, widely used and normative (vs. Adobe's "The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Adobe Systems Incorporated."). Oh, and it's still being updated and developed further.

A PSD file is akin to source code or project files imo - ie the working format for the artists. Giving this to the coders makes as much sense as giving source code to the artists. Delivery of assets should be done in "final" formats in the variations needed, and the specifications of this would be completely dependent on the project.

The standards should be, "whatever the code department needs, within reason". This may involve the coders writing exporter plugins for artists. But there is no standard way of distributing art since there is no standard way of consuming or using art. It's just down to what the technology pipeline requires.
However, as some rough guidelines:

First, ask what they want. If they want a certain texture format, eg. DDS or whatever, ask and they'll say so. Check to see if you can export in this format, and if not, confer with the team to decide on how to proceed. Maybe they'll need you to install a converter, or maybe they'll let you supply the images in a different format.
Make sure you have a consistent storage system for your assets that corresponds to the game's data. At some point you will be asked to redo assets, and therefore you will need to quickly find individual assets when told about a problem in-game.
Use common sense. Use lossless formats when they won't be too large for little gain. Use lossy formats when they are much smaller and don't lose you significant image quality. Keep lossless versions around in your own control system so that if lossy versions are unusable, you can still generate a lossless one.
When producing GUI elements, again, ASK how the system works. Don't waste your time producing mouse off/over/down/focused images when the system probably does not support all those, and might well implement some of them directly via hue shifts or alpha or whatever. Don't produce a precisely-sized dialog when it turns out they use a nine-slice system to allow dynamic sizing. Ask exactly what format they use, then supply it.
Don't render text onto a background unless you have confirmed this is the right thing to do. eg. If asked to produce OK and Cancel buttons, that usually means you make ONE button and then the code will render the words 'OK' and 'Cancel' over the top. When that game is translated into French later, this means someone just has to change the 'Cancel' string to 'Annuler' and you don't have to go back and produce another set of buttons.
When producing any asset type for the first time, deliver one to the intended recipient and get them to verify the format and dimensions are correct. You don't want to crank out 20 buttons and find out that they are all wrong.
Establish texture sizes and overall budgets before delivering textures - coders hate it when you deliver 2048x2048 textures for something that only ever takes up 10 pixels on screen. Similarly, if the colour is uniform across the whole texture, you do not need 2048x2048, or even 128x128 - you need 1x1. More generally, deliver the smallest asset that delivers the visual quality you need.
Establish consistent and descriptive naming conventions. If you generate buttons in off/selected/on states, name them quit_button_on.png, quit_button_selected.png, quit_button_off.png, etc., and repeat this across all buttons you ever make. If you generate several asset types for one object (eg. mesh, anims, textures), name them similarly if appropriate. I've known several artists who don't understand why coders have such an OCD attitude towards file names - it's because arbitrary file names waste our time. It becomes harder to find the right assets in a directory of hundreds. It becomes hard to flick from one to the next and back again easily to verify size changes and labelling is correct. It's difficult to know whether it's the code or the art which is wrong when something looks incorrect on screen but the debugger lists the texture only as "aaa34_345b.dds".
Do what the programmer wants - but make him help you do it. If saving in the relevant format is a burden, or checking the texture budget is impractical for you, or they want all assets in a special archive format that only one obscure piece of software can use... get him or her to write tools and plugins to help. A week spent on appropriate art tools can save both the artist and the programmer much more than a week of effort later. Don't let your code team skimp on tools.

The artists were able to keep the raw assets in any format they wanted. They would then export the files to a specific format, either from a plugin to Max/Maya that we made that would dump the data out in our format or simply saving as a PNG for photoshop and the like with the quality settings varying from project to project (ie, from target platform to target platform).
The files would then be processed into their load-time format by an asset compilation tool for faster load times.
However, this was just the way we did it. I would imagine alot of examples would follow along this line and there may have been guidelines above and beyond what I was aware of that an art director might have placed on top of the technical limitations depending on styles of art, but in general I think you will find the basic 'Artists keep it in a raw format and export it to a game engine specific format that is then further processed' as fairly standard at most large and even mid level game companies.

as a coder I just ask them what assets are the going to create, and then create a sample asset of those properties. give them the code and let them play with my app until they think output is good enough.

As a student I can't give proper advice as to what is done in the industry, however, when working on a group project the programmers were "in charge" and told the artists exactly what they needed. In addition to the guidelines provided at the beginning of the project they were also expected to follow the requirements provided by the programmers.
There was a lot of going back and forth when an artist didn't understand that the color R:254, G:0 B:254 was COMPLETELY DIFFERENT from the required R:255 G:0 B:255, was therefore unusable, and they had to start over.

On the other hand, you, as a programmer, could've trivially made your data loader change 0xFE00FE to 0xFF00FF. Like Kylotan says, programmers get to be anal to artists about formats because programmers also have a responsibility to make the tools.

@Joe: he couldn't change it because likely he had some images 0xFF00FF and some others 0xFE00FE. Moreover, people have to get used to do stuff in a proper format if that has been requested: circumventing their errors creates a flawed workflow.


text:
How do I add a custom mob to Minecraft?
Basically decided to make my own mob, I have:

Created my mob's entity class
Created my mobs model class
Drawn the model
Added the function call for addMapping within the EntityList class

I'm stuck on what to do next. I've tried finding the code that deals with passive animal spawning in the world, however I can't seem to find it.
Help greatly appreciated.

I've made a new proposal for a modding site on stackexchange, if you want to give it your vote. Can't hurt, even if someone answers your question here.

And do a search on "minecraft", you will find results on this site re modding that game.

World.java:2818 - during the tick method - SpawnerAnimals.performSpawning(this, spawnHostileMobs, spawnPeacefulMobs && worldInfo.getWorldTime() % 400L == 0L);

Well I'm not going to write a whole tutorial (because I have limited time right now) but I will link you to some resources and give some tips.
Firstly if you are going to mod Minecraft in any way, you want to go to the modding wiki.
I had a look around the wiki, and found a basic mob creation tutorial.
There is a massive mod creation tutorial here. You should have a skim through that
I picked out some individual tutorials that you might like-

Create a new mob (they call it NPC, same thing)
Controlling a custom mob's movement

Now on to the model creation, this took me a while to find, but I found 3 modelling programs.

Techne - Allows you to create models, which will then be converted into Java code. has alot of user tutorials on how to create replicas of vanilla models (cows, endermen etc.)
MCModeller - Quite simple GUI, live preview. Coded in Java
FMCModeller - GUI is not as simple, but it looks extremely professional with 2 view, one for the spritesheet and one for displaying the model live (which you can rotate etc.). Coded in Flash.

For the passive animal spawning code, I suggest you download Minecraft Coders Pack MCP, and search through the source files. The way I first found how to mod the terrain generator, was searching the source directory for the blockID I was modding. I suggest you search for terms like "spawn" and "entity".
You must understand however, that when Mojang releases modding support, this will be much easier, so be prepared to change your code. Also with the newest Adventure Updates, Mojang is constantly changing the code.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
What makes a computer opponent feel alive?
Are there any recommended blogs or whitepapers that talk about making the AI in an RPG game feel more real? (Specifically in turn based combat.)
I know something must be out there, but I am only finding papers that talk about algorithms  behind the AI. I am looking more along the lines of "this is what makes a computer opponent feel alive". Taking risks, going easy, retreating, etc....

So many awesome answers, and I wish I could accept several of them. Thanks everyone!

If the computer comes up with a strategy, that makes it feel more alive.  FEAR's AI was praised because it would flank the player (among other things) (though I believe much of that was actually scripted)

Its death animation. Bang. No but seriously, using the environment against you. And making mistakes -- but clever mistakes. Right? Like someone who has foresight, only he made the wrong assumption at some point in his chain of reasoning.

It is not clear if you want that the computer characters feel alive or that you may have the impression to fight against another human player just like you that controls all computer characters?

How to make a computer feel alive : watch Bladerunner again ...

You might want to read this. It uses fuzzy logic over a decision tree.

Mistakes. Nothing is worse than an AI opponent who can headshot you from fifteen miles away, or always picks the perfect winning strategy. It breaks the immersion and makes it apparent that you're playing a routine. Mistakes can make the AI seem more human.
Many FPS games force the AI to miss with its first few shots, warning the player that the AI is there, before going for the kill.
Strategy games could sometimes select a suboptimial strategy, or when evaluating threats may purposefully ignore some proportion of them.
A racing game I worked on calculated when the player was nearby, and then rolled a dice to make the AI cars in front of him understeer through the corner or blow a tyre. It was praised for its realistic AI.
However creating imperfect AI is still something of a challenge. You have to make convincing mistakes, at a convincing rate, rather than perform perfect action after perfect action until making a ridiculous blunder. That can be even worse than playing just a perfect AI. For instance, the programmer working on the racing AI above spent a lot of time on modelling how a car understeers, and what inputs the AI needs to make to cause a convincing understeer. As always, playtesting is vital.
Here's a good article on what goes into producing these kind of mistakes:
http://www.gamasutra.com/view/feature/3947/intelligent_mistakes_how_to_.php

"Many FPS games force the AI to miss with its first few shots, warning the player that the AI is there, before going for the kill": In GURPS we called this Imperial Stormtrooper Marksmanship Academy training.

Too many mistakes and it's a dumb computer.

Infinite energy is created by placing a bunch of red-shirt guys in a jail cell next to a bunch of storm troopers. The storm troopers can't hit their target, and the red-shirt guys have to die.

I do get the point of the answer and I think about the line between perfection for a computer and perfection for a human being.
What does change? A great quake3 player like fatality in what is different from a cpu at nightmare level?

I calculate all possible moves an AI can take, assigning weight to moves based on the circumstances and the AI's assigned personality traits (such as bloodlust, afraidOfDeath, anger, etc). This works great for scenarios like: you and the AI are about to die, a straight-forward AI would shoot you then grab the health pack, but an AI high in afraidOfDeath will try and beat you to it. Unless they have high anger or bloodlust, then they just shoot until one of you is dead.

See also: http://gamedev.stackexchange.com/questions/12858/what-behaviors-should-go-into-making-a-non-perfect-ai-combatant

Others have talked about AI, logic, planning, and the importance of making mistakes.  And all of these are good and useful in the development of AI.
But the question was about what makes a computer opponent feel alive, and that isn't achievable through AI.  It just isn't.  Players don't judge a character in a game based upon their strategic level choices;  they judge it based on much smaller things.
To make a computer opponent feel alive, what you need is a comprehensive set of high-quality animations and sounds (vocals, especially) for the opponent.  The player can't see the AI.  He can't hear it, he can't experience it, he can't know what the opponent is thinking.  The appearance of "this character is a living entity" is presented to the player entirely through the animations playing on the character, and the sounds being produced by the character (which again, will mostly be vocals).
It's important for the character to react to stimuli around him;  to look at things nearby, to touch objects nearby (when appropriate to do so), to appear startled when surprised, and to show other emotions when appropriate.
When talking about these things, it's important to minimise repeats.  If the character uses the same "attack" animation every time he attacks, he's never going to feel alive.  If he plays a single looping "idle" animation when he's not doing anything else, he's not going to feel alive.  If he says the same voice quip twice (especially consecutively), that breaks the illusion that the character is alive.
And that's pretty much it.  If the opponent that you're trying to make seem alive is physically present in your game, then your success at making them seem alive will mostly be determined by the graphics and sound shown to the player.
If the opponent that you're trying to make seem "alive" isn't actually present in the game, as is the case in Chess and StarCraft, then feel free to disregard this reply;  your best bet is to follow the AI-focused replies.

Reminds me of all the enemies in Mass Effect shouting "ENEMIES EVERYWHERE!" every 2 seconds.

I wish I could up-vote this SO MUCH MORE. I've worked on two triple-A FPS's and can't emphasize how important quality animations (peeking, gesturing, moving) and audio (saying intent, questioning, conversing) are to creating a great environment. AI isn't about beating the player, it's about conveying realism, a huge portion of realism is how we move and sound.

+1, good points. Made me think of Oblivioneque games where your attempt to interact with an NPC sometimes is hindered by them sitting up in bed, turning sideways, standing up, and finally facing you, before finally acknowledging your presence... that always messed with my immersion.

Agree that this makes a more immersive gameplay, disagree that it makes it more human. Ever watched how many HUMAN players behaves in most multiplayer games? In some games, half of the players are jumping around for no purpose and the other half are spamming the voice chat with the same voice clips twenty times a second. The bots are often better behaved than the humans.

One of the way you can make an AI looks human is probably to make them ragequit if they keeps getting killed. Or attempt to trick a new player into trading expensive items for useless bling. That wouldn't be a fun game to play, but at least the AI will feel "alive".

@LieRyan It sounds like you've misinterpreted the question?  You're proposing ways to make a video game character behave like it's being controlled by a real human (who is being a jerk).  The question was actually asking about how to make a video game character behave like it is a real human.  Jumping continuously or ragequitting (or indeed, "getting killed" more than once) would completely fail at the goal proposed in the original question.

Ahh the superb greeting option of John Marston in Red Dead Redemption. From the masters of video games. R* :- )

I'd like to add that good dialogue also helps a ton to make the characters feel alive.  For instance, the game Outer Wilds.  You never meet the Nomai, or even see them, you only read their written language, but the dialogue felt real enough to make them seem alive.

Here's a list of some simple concepts that can make your opponent more vivid:

Intent
Give the player some way of divining the 'intent' of the AI. This could be as simple as having them yell out "Quantity over Quality" before attempting an accurate headshot attack, "Flank him" while attempting to get behind you, or "Take the leader, nothing else matters" before attacking the protagonist. You could also get more complex, for example, have them give some sign language to their teammates, then change the behaviour of those teammates.
Desperation
As the opponent gets closer to death, you can give them a sense of desperation. Change their tactics at certain health milestones. Make their later stages more panicky, with greater risk taking on their part (going for the hail mary, rather than slow chipping). Visually communicate this as well (more exaggerated animations, pulsing veins, etc).
Go out with a Bang.
Give them a death that makes the fight with them something worth repeating. Grunts keel over animatedly. Bosses soliloquize. If it's a proud character, make them refuse to give you the kill, and deal the last of their damage to themselves. You get the drift.

Hi. You really do not have to write you qualification into your answer. Fill into your profile and if somebody is interested if you know what you are talking about, hi clicks at your name. That's it ;).

The intent point is a good one. A good strategy is to have your AI teammates (if they exist) call out what the opponents are doing - "they're flanking!", "they're reloading!" etc. In fact this strategy is quite effective even when the enemy AI are doing no such thing. :)

+1 Good points you've listed! Also be aware that most of the time the goal is not to make an AI that wins, but to make an AI that is fun to play against. Meaning that the AI should give the player a (do-able) challenge.

@Notabene, not disagreeing with your comment, but as a note - you have the rep to edit out the extraneous information yourself. :) I just did the edit, but it's "subject to review" for me. :)

@Cyclops. Yes i considered that. But it could feel pretty rude without proper comment and i wanted to let Jordaan to decide on his own about it. I mean that friendly of course. But lets stop destroying good answer with of topic comments :]

Hey. Just to let you all know, I included the Bachelor Degree line as a form of self-deprecation. Here in Australia, a Bachelor of Games degree is not worth the paper it's printed on. There was no intent to brag. "Here's some obvious advice thats the culmination of my wasted $30,000 and 3 years of study". Sorry if I didn't convey that correctly.

I do recommend this google IO talk it is about google doodle pacman. At cca 18:00 they start to speak about personality of ghosts in pacman. It is really stuning how simply you can put personalities into the simple path finding.
Google I/O 2011: The Secrets of Google Pac-Man: A Game Show
Whole video is worth watching. I really recommend it.

Not really answer the question, but could be inspiring... (i guess)

I'd say it's a valid Answer. The Question was about how to make a computer opponent feel "alive", and designing the ghosts' personality does exactly that.

I don't know about any such blogs, but since a tactical turn-based RPGs is my second favorite genre right after roguelikes, I'll write you a blog post. From my experience, it was not a difficulty of tactical AI in a RPG or RTS which often put me off, but its opposite: AI's complete short-sightedness and absence of team decisions. Human will never play like this.
Back then, when I still viewed JRPGs as a pinnacle of game design, I once tried to make a "typical japanese TRPG" with heavy focus on tactical turn-based combat like Final Fantasy Tactics. As always, it became just a tech demo for pathfinding and AI, so I'll share my thoughts on the subject.
Most of these TRPGs don't bother with AI much. Player's fun out there comes not from a complex tactical or strategical challenge, but from general farming and abusing AI in a funny way. So it doesn't matter much that their AIs do things no human would ever do. Usually it's sufficient to have a stupid AI and balance it out with game design in way that it never needs to see more than one move in advance and only use best short-term moves. Of course it never feels real, but who cares? This just feels wrong, I want to believe it is possible to create fun based on a battling complex AI actions instead of farming and steamrolling. Unnecessary maybe, and time-consuming as well, but possible.
Remembering original Final Fantasy Tactics and its hardcore mod FFT 1.3, I set the following goals for human-like and fun to play AI:

AI must create a challenge, but a fun challenge and not a "human full search" challenge. This fun challenge should be often expected by player via overall context of a current mission. Usually thats where scripts come into play creating a one trick pony AI.
AI should be clever, but not deep Minimax clever. Different types of AI should have different flaws, just like different human personalities would. It's a rare thing to encounter in games, Advance Wars had scripted personalities for generals, for example, but units can have them too.
AI must avoid looking dumb when it is not intended. Obscene stupidity completely ruins any illusion of intelligence, always winning strategies do so as well. And loopholes created by careless scripting, those are the worst.

I thought that I will tackle #1 with emergent behaviours, #2 with different personalities and human-like "semi-random" strategy choice, #3 with keeping hard-coding to a minimum and a careful testing.
So what are these behaviours I'm what talking about, is it a scripted sequence of abilities to use? A top ability from a weighted list? Nope, what I had in mind was a combination of a desired intelligence, personality type and a role derived from currently available abilities and weapons. You can describe this combination as a "stupid berserking damage dealer" or "smart defensive healer". So AI specializations, like classes or professions, e.g. an Archer AI which uses bow to shoot arrows with some set of predefined generic archer ability combos like Take Aim or Arrow Shower, become logically emergent instead of hard-coded.
Basically, it is important to detect and operate on these roles: damage dealer, damage soaker, disabler, skirmisher, healer, buffer/debuffer, area of effect'er; usually, one character will perform at least two of these roles.
To make a tactical fun out of this we want for behaviours to handle several cases solidly:
Simplest case. A lot of weak goblins ambush our heroes. Perceived threat is obvious, goblins will try to overwhelm player with each goblin having a stupid berserk personality with some primitive melee abilities, perceived weakness is also obvious, like baiting goblins to a single armored and fire-resistant character, then casting a series of fire-based AoE spells in that general direction. Find a damage soaker, find an AoE'er, specialize the damage soaker for AoE'er damage type, send the damage soaker to the goblin mass, cast a damaging AoE spell when goblins group around.
Usual case to test out simple team interactions. Player encounters a knight, an archer, a mage and a cleric. Perceived threat is now more complex, various interactions become available. YOu can already see possible roles and its combinations. Cleric will buff and heal, mage will dish out complex but high-damaging magic things, knight will either charge someone or defend a mage, archer will help knight by sniping those who try to run away from him or making his defence strategy more comple, this will depend on knight's choice. Personalities for enemies may be decided randomly turning the same encounter into unique experience. Player will have to decide what is the best strategy with units he currently has, and if AI would try to do the same on the other side of the screen, it would be interesting.
Complex case to test out team interactions and strategic planning. There is a battle where you confront a gang of four assasins (clever careful damage dealer+skirmisher). Few in numbers, with menacing appearance, their perceived threat lies in skillful and deadly attack, and perceived weakness is that it's easy to reduce overall strength with just a single assasin killed. So naturally they're clever, they use abilities that work well with each other and can focus fire player's most dangerous characters; seriously injured ones retreat, heal and buff themselves to rejoin the battle. Obviously, player will try to nuke one of them first, and assasins will have to soft-counter this easy strategy, so it will be a less dominant.
Hard case for lots of strategy. There are several squads of enemies with each squad leader deciding best local tactical moves, and then a best global strategic decision is selected to benefit all squads.
Impossible case. Add a general to decide a strategy, and have squad leaders implement it to the best of the squads abilities.
It's a lot of letters already, so long story short, implementation was a mess and I never got past a "hard case", but even then this approach to a fun tactics felt doable. I started with FSMs but had to abandon that approach quickly, it became an entangled mess of states and transitions impossible to debug. After a while I settled with semi-autonomous ability perception based characters as in "sense-think-act" paradigm with behaviour trees for possible individual actions, a global strategy affecting possible team actions based on possible individual actions, also a bastardized version of something like N-Gram statistical prediction was tossed in.
How has this worked out? Surprisingly well, AI even read my mind several times, but I grew tired and abandoned it since there were more than enough convincing flaws:

The biggest flaw was that sometimes the entire AI operation was just weird and chaotic, even though I punished quick change of strategies. Probably either strategy logic or wrong personalities were a culprit, but I never found out. Yep, code architecture was horrible.
Fine-tuning desired scenario by a careful selection of available abilities and personalities is tedious.
Ability tagging for roles should be done very careful, or some wacky combos would appear.
Same for personality tagging, but instead of wacky combos you would see careful casters buffing for frontal assault.
It was hard to decide on a "cleverness" level for a given ability.
Some seemingly stupid decions which were required for a level-design like "hold this castle wall no matter what" had to be implemented in a hackish way.
Planning for units to perform a time-based attack was also a hack.

I guess my approach was mediocre at best, if not outright bad, and AI was buggy and pain in the ass to develop further, but even then I had some really fun time playing against it, almost as if playing with a distracted kid, which is still better than Tactics Ogre :)

I found some of your ideas quite stimulating, and with some tweaking, may improve the AI on a sim I'm working on.

@jumpnett Good to know, I was hoping that at least a general idea could be understood :) As a bonus you get to hear more of my crazy thoughts, now on your sim. Imagining a real-time sim, I think one of the most important choices would be a tidy task scheduler logic.
I guess I would've tried to organize tasks that way:
There would be main tasks with priorities, a "strategies" like "build a house" with prerequisites like "4 workers; 4x4 square of free nodes at point 10,10; 10 wooden planks; 20 stone slabs". Strategy will be considered done when all prerequisites are met.

Each prerequisite would spawn a sub-task to achieve corresponding prerequisite; sub-tasks can be parallel, sequential or even mutually exclusive. When task ends successfully, set it's prerequisite as complete. For example, "10 stones" task is sequential for "4 workers" and "4x4 place" tasks, since you can't gather stones without workers, and you can't place stones without a place, but it would be parallel to a "20 stones" task, since you don't want a situation where you have lots of stone but no wood, and your workers are just standing around waiting for wood instead of using stone first.

Thinking about tasks in terms of prerequisites is generally very useful, like when a new strategy task is placed in a scheduler, you may want to know whether it can be started immediately or not. With this system you can easily gather all incomplete prerequisites of tasks with higher priority and check whether new task's prerequisites are conflicting with them.

The main bottleneck here is a resolution of sub-tasks which can not be completed. These comes in two kinds: 1) can't complete now and 2) can never be completed. generally for a #1 you'll want to create a new strategy with higher priority which will help previous strategy, and for #2 you'll want to abandon strategy forever. Thing is, it's hard to distinguish between these 2 kinds, can't really say much here. Well, maybe your approach is already like this, but maybe you will scavenge for some more ideas :)

Don't always make it respond to your action X with action Y.  As you evaluate each potential action add a random fudge factor so the AI doesn't always pick the same option but it chooses something reasonable.
Evaluate if an attack has a reasonable chance of succeeding or at least doing meaningful damage.  Too many games simply have scripted attack routes that a human can learn and use to ambush the AI over and over.

One thing I see suggested a lot is to have the AI communicate its "thoughts" to the player in some way. This is often done in first-person shooters by having the enemies (unrealistically) shout out their plans to the player (i.e. "flank him!", "he's over there!", etc.).
At the end of the day, players know they're playing against an AI, so anything smart that the AI does without first informing the player can just be dismissed as cheating.

In assasins creed When you were chased the pursuers would yell out "He's over here!" or "Where's he gone?" or some such to other pursuers. So IMHO: it can be realistic.

True, it does make sense in many cases, and it can depend on the context of the game. The guards in Assassin's Creed would have different ways of communicating than, e.g. a modern-day SWAT team. And often the realistic solution isn't necessarily the most fun; it can be frustrating to be constantly flanked by the AI with no warning.

When talking about game NPCs most people associate liveness with intelligence, but emotion would probably be a much better indicator.
A hostage NPC in a bank robbery might just be sitting on the floor not doing anything "intelligent" but trembling, crying, holding a picture of family would bring an otherwise dull NPC to life.
The same thing is true for enemy NPCs. They would get enraged or fearful if you keep headshotting his pals. If you're sneaking around you could hear some rookies that are hesitant in going into combat. You could overhear their leader doing an inspiring speech to get the morale up.
Take a look at the Heider-Simmel Illusion where a psychologist shows that people have a tendency to see human-like behaviour everywhere, even in super abstract shapes. The video has no realistic animations, audio or models, but it has emotion.

Often, we think of "how do we create A.I.?"
That is skipping the big question, "What IS A.I. ?"
This talk from TED.com that I watched some years ago, shared a very inspiring approach to the definition of Artificial Intelligent.
If you want your players to feel that the enemies are "intelligent" then this will provide a high-level answer, and essentially a whole new way of thinking about A.I., which is the "ability to predict"
http://www.ted.com/talks/jeff_hawkins_on_how_brain_science_will_change_computing.html

To me, "feeling alive" means that the character act as you would think it would in real life.
People in real life have needs, motivations, fears, flaws. They talk, they react with each other if it is a group, they flee because they care for their own life.
If they are military or trained, they have tactics.
So maybe you should check in the field of human behavior, so in human sciences, not in computer sciences.

Hmm not sure about this. Above everything the AI has to be fun. Is it fun for enemies to flee? Surely it's more fun to fight them, since the whole point of the game is to fight?

It depends what fun you want. People find fun in simulations , others in arcade games... what's the one that feel more on par with real life?

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Video game entity storage and structures
I finally have all the working input/output of a game engine.
However, I'd like to be able to put an amount of about 2000 shots being simulated in a region, total. I have done other games where all the data was stored in a linear array and iterated every turn, and referenced by index number.
This method seems to be fast enough, grants random access instantaneously and I'd say it "just works". However, inserting a new element requires searching for an empty space, and iterating over the "inactive" shots.
Considering the amount of max shots, what would be the best approach to this? Am I thinking too much about this, perhaps, and the array is a good enough system?
The engine works in C99. Shots will be destroyed when out of "practical" range and collisions will be done around the player rather than the entire working map. The game is real-time action style so updating needs to be quick, and shots might need to be accessed by position, which is another weakness of the array approach (unless I add that information to "slices" of the main map, I guess).
To summarize. What would be the best data structure in terms of insertion speed, allowing random access and iterating without gaps? A name, if it exists,  would be enough.

I'm a bit confused but from what I can see you may want something like this: http://stackoverflow.com/questions/7252274/getting-unique-numbers-and-knowing-when-theyre-freed

I will invoke the magic words: Measure Before Optimizing.  You probably don't even need to do anything more and any effort you spend now will be better spent on bigger problems or better game play.

I don't think you can find anything other than "array" if you want random access power. "Hash" could be it but using "hash" for saving shots doesn't seem to be right. I would stick to "array" but change the way of finding empty or inactive slots.
The way I used for my game is

Define one indexFirstEmpty pointing to the first empty slot.
Insert a new shot into the first empty slot and increase indexFirstEmpty .
Delete a dead shot by swapping it with the last valid shot ( slot[indexFirstEmpty - 1] )
and decrease indexFirstEmpty. Don't forget to check valid range and self swapping.

With this way, you don't have to iterate the array to find an empty slot. This works because I don't care the order of shots in the array as long as they are partitioned correctly. If you want to keep the order of shots, you need a different way but it will be slower than the one I suggested. Good Luck!

How do you know it will be slower if you don't know what it is?

Because it will require more work to keep the order. no?

Can you move stuff around in your array? Something I've done in the past to keep items packed (when the exact sequence is irrelevant), is whenever you delete something out of the middle somewhere, relocate the last element of the array into the empty slot. This keeps the storage tight, so you can always add a new element at the end in O(1) time, without worrying about all kinds of holes.
Another thing you can do is add a field to the struct (assuming your array is an array of structs) to implement a singly linked list for the "empties" in the array, in this case, the new field is the array index of the next element in the list. Now, it's a singly linked list, but you use it like a stack; always add to/remove from the head end. You keep another int that indexes the first element in this free-elements list, so you can always allocate an empty slot in O(1). Whenever you free a slot, you set its next-element index to the current head of the free list, and change the head to index the just deallocated element.

All 3 suggestions sound pretty good. I am mostly inclined towards Young's and Quasiverse's answers (I think with a stack). JustJeff's answer is also quite interesting, and I might use that one for other type of entities.
On second thought I might not really need to keep track of the shots in exact order although the order-aware answers are still certainly useful.
Thanks a lot everyone! Unfortunately because the post was moved (honestly didn't know there was a whole game dev Stack site....!) I cannot pick any of the answers, sorry about that.


text:
Algorithm for a tool to theorycraft stats based on a game(league of legends)
I would like to create a simulator(basically for testing purposes) for a game(League of legends).
The basics of the game:
you have a hero which has some stats:

Health Point
Attack Damage
Attack Speed
Armor
Armor Penetration
Movement Speed

Hero can have 4 skills(you get one skillpoint at each level)
(They are activated manually, most of the time, has cooldown, damage, attackpower/attackdamage scale ratio, and skill level)
+ a passive skill
You can kill enemy heroes, or neutral monsters, they have the same stats:

Health Point
Attack Damage
Attack Speed
Armor

What I would like to do:
Create a tool to test if a particular item, or a particular stat increase would speed up your killing power/speed.
map: http://evtron.com/Evtron-Alpha/wp-content/uploads/2011/02/Summoners-Rift.jpg
Stat examples:

Hp: 420
Ad: 55
AttackSpeed: 0.613 ( attacks / s -> every attack at 1/0.613 s)
armor penetration: 25

The character gonna autoattack the enemy with the 1/attackspeed, and damaging with attackdamage(there is a formulate to calculate the damage, but thats not important in this phase i guess), once they are dead, moving to the next one with movingspeed(you can see the camps on the map, the yellow skulls)
I was thinking about the algorithm:

I thought if i just make a for from i=0 to i=30000(counting ms), so I can just check the enemy hp and my hp as well at every ms turned out so bad(pretty cpu heavy, and i would like to put some random in it, so i should be able to sum up 1k iteration, which is impossible)
Secondly, i thought i should just do a for from i= 1 to 30, and check every second, and check what happened in the last second, but some of the neutral monsters are in a big camp (up to 4 monsters), and this way the code was getting complicated and complicated.
I'm gonna create threads for each player/monsters, and once they finished look up when they died, and reduce the hp of the player.

My question, is this the right way to go?
TLDR: I would like to create a tool to create analysis(iterate 1k and calculate average) about a game which stat increase would make the character killing faster neutral monsters.
I would prefer java, but atm I'm stuck at the algorithm.

@Karoly S: Yep, it' my bad, .com -> .eu
I've been working on this:
I'm checking the remaining time on each object(player skill, autoattack, buffs), and always pick the shorttest time, and store the last_time, and add the time to time, at the next round I calculate the time by (time-last_time)
If the object has remaining time 0, it will do whatever it needs to do.
I don't know if it's effecient way or not, but that's the best I could do.

You might have better luck asking on the Game Development section/site of Stack Exchange, try to get a Mod to move it, though chances are they will anyways. A jungling simulator would be kind of interesting, I'll give it some thought and see what I come up with.

Thanks for the quick answer, your help is much appreciated. My guess is right that you are hungarian too?

Absolutely, this is something I've thought about though not nearly this in depth, but I would be interested in. My initial approach would be to see if an effective though simpler version of your #2 is possible. I would love to discuss this with you at greater lengths. And yes, your guess would be correct :)

Sounds cool for me, I will leave the topic open, maybe someone already has an idea about it. my email (etheld at gwelican dot com)

Sounds good, I'll put some thought into it and email you a little later today.

Just tried to send you an email but it keeps coming back, any ideas?

Alternatives to frame-by-frame simulation:
You can get kind of a reasonable approximation for simulation by a formula such as
rawDamage = <some function of strength?)
Damage = rawDamage - enemyArmorReduction
DPS = (attackSpeed * Damage) * enemyArmorMod
myRemainingHP = myDPS / theirHP  - theirDPS / myHP

You can also maintain a move-queue, so that you simulate per-move, not per-tick:
// my aspd = 4 attacks per second, his aspd = 3 attacks per second
0.0s : start battle
0.25s: I attack
0.33s: He attacks
0.50s: I attack again
...
1.00s: I attack
1.00s: He attacks
...

The move queue will be more accurate, as it correctly deals with the fact that damage is discrete, not continuous. For example, if I do 50 damage at 0 seconds, and another 50 at 1 second, My DPS would be 50, yet I would kill a 100 HP target in 1 second.

@hammar: that's true. the shorter the fight, the less accurate a DPS-based estimate will be.

The fact that the game has stuns and other debuffs would make such a tool really hard to achieve, because different players could have different results in they killing rate. Anyway good answer.


text:
How can I animate a recursive algorithm?
Say I have a recursive algorithm, for example one that generates a random tree:
// Pseudocode, just a simple algorithm: it isn't perfect.
function generate_branch(angle, length, current_depth, max_depth) {
  var branch = Branch(angle, length); // creates a new branch
  if (current_depth == max_depth) {
    return branch;
  }
  current_depth++;
  // random_int(min, max)
  branch.subbranches[] = generate_branch(random_int(0, angle + random_int(-30, 30)),
                                         random_int(0, 20)
                                         current_depth,
                                         max_depth);
  // ^^^^ recursion
  return branch;
}

var trunk = generate_branch(0, random_int(10), 0, 5);
RenderTree(trunk);

The problem is that this will render the entire tree in one frame. If I want to animate this (i.e. grow the tree over time), how would I do that? What is the best way to do this?
The game uses a game loop.

You store the current depth of every branch for each node, and append Rendertree to render all nodes up to a specific depth, given as a parameter.
This way, you can show each depth level seperatly.
Pseudocode could be like this:
Generate tree

While(GameLoopRunning)
  begin
    for i := 0 to maxdepth do
      begin
        RenderTree(trunk, i)
        delay(250); //should not be like this, will block entire game loop.
      end
  end

Edit:
You might want to use some kind of timer to fire some kind of GrowNow!-Events to your game logic in order to avoid the for-loop and delay in your main game loop.

Good idea. I can put the "GrowNow!-Event" in the Step() method of the tree. Thanks for the feedback.

You could also have the generation and drawing on seperate threads.

What you can do is save a stack of the process you need to do (with all the parameters and depth), and only process one branch at a time, which will add one or more other branch to the stack.
This way you'll draw one step at a time. Of course you can choose to process more than one branch from the stack at a time or wait a delay between each process.


text:
How do you organize your game files and classes?
Although it isn't necessary to exclude things like graphics and audio packages, I'm most interested in the organization of the folders for classes that deal with AI and game state. I'm thinking something like this in Java using packages as the example:
import com.rpg.characters;
import com.rpg.characters.antagonist;
import com.rpg.characters.neutral;
import com.rpg.characters.protagonist;
import com.rpg.characters.state;
import com.rpg.gameplay;
import com.rpg.gameplay.engine;
import com.rpg.gameplay.maps;
import com.rpg.weapons;

Also, does it make a huge difference between 2d and 3d games?

Are you asking if separating out the different packages has a performance increase?

@Tetrad No, I want to know from someone who has designed a fully-featured 2d (or 3d) game how they organized the packages. Architecturally, I think it gives insights into the design without asking for the source of an entire game.

There was also a question I read recently regarding MVC in game architecture, and how it wasn't a good fit (based upon most comments). If that is a case, then there must be an organizational structure that is preferred as an alternative. Listing the package structure I think would help flush that out a bit, even if it isn't a commonly known design pattern.

Efficient in what sense? Could you use a better word to describe what exactly you're looking for? If you're just looking for code organisation tips, that's probably not AI or game-state specific (but neither is it language-agnostic). If you're specifically interested in how people handle AI, then the first thing I'd say is that we wouldnt normally have 1 class per type of character.

I'm not sure how "language agnostic" this question is, as there are many languages used for game development that do not have "packages". The bigger issue is that package organization does not give you any real insight into design. The important part of design is the interaction between classes, which package organization doesn't show.

@Kylotan So I removed the language agnostic and state tags, and I will clarify by saying that Pablo's answer is getting at what I want to know.

@Nicol I completely disagree that package organization doesn't give you insight. There is a strong correlation between how you organize packages (especially in Java), and the design patterns you use. I think the question is too difficult to understand in it's current state, and I am going to revise it.

It's an interesting question. Are you interested in making an rpg engine? or just a game? I believe rpg engines are very reusable if you keep them separated from the code for graphics and other resources

@Pablo At the present time I'm creating an RPG engine, mostly to flush out the battle system. I'm using Java and then Jython for scripting, and it has been really helpful to view open source games on SourceForge to get a feel for structure, but I figured I would ask here to see if anyone had other suggestions as well.

@Brian I would go for books and articles instead of open source code. AI topics would be good because that will help you a lot for designing the engine on your own according to your needs. You also made clear that you're not making a game, which then lets you focus on the abstraction features (required in a game engine), and making so specialized packages you lose abstraction and increase the programmer's work.

Usually, I start out with one file. Then, as time passes, I would eventually have:

Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
Player: AbstractPlayer, Score, Input, Collision, Reaction, Skill, Inventory, ...
Map: AbstractMap, Area, Town, NPC, ...
Enemy: AbstractEnemy, Creep, Boss, BaseAI, FuzzyAI, ...
State: IntroScreen, MainMenu, LoginScreen, Game, PauseMenu, ...
Interface: Button, Text, InputBox, ...

This is only for the client-side of the game. XML, Lua, Javascript or SQL databases are useful for defining many different things especially different classes of players, maps, NPCs, enemies, items, quests, skills, etc. I like XML though, because of its simplicity, and its data can be parsed by any other language.
Game files are usually stored in a package file like ZIP or similar resource. I have a resource loader that looks for a file in the package, then if it can't be found, it locates the resource in a directory, or some other place. This allows me to develop quickly.
3D games are no different, but they are more complex. They need model loaders, instancing, and must use vertex buffers. They consequently make heavy use of shaders to provide other effects like lightning, bump maps, environment maps, etc.
Most 3D games have a game engine backend to do all this for them. For Java, try jMonkeyEngine. For C++, try Ogre3D. For Python, try Panda3D.
In my experience, it is better to hardcode everything whenever you can, unless the feature is specifically required. This allows you to develop the game faster, and refactor later.

I believe is a bad idea to have antagonist and neutral and protagonist as different classes, unless your antagonists are multientity spaceships and your protagonists are mages, of course. I agree with Nicol that this is not really language agnostic, and I believe is a really bad idea to try to resume the game architecture like that. Just make a comment in the beginnig of the file or a companion .txt if you want to give insight.
Even so, I would do something like this (following the kiss rules):
 // I'm assuming java, this may not be possible if java doesn't like kiss rules
 import com.rpg.characters;
 import com.rpg.engine;
 import com.rpg.maps;
 import com.rpg.weapons;

I would recommend that if your language allows this, it probably gives the same insight and it's much easier to work with. Even if I don't have a clue about what language are you using (i'm guessing java from import com.), I would do it this way, and I could leave your approach if I were using a "characters" package that contains lots of character types and you just want 3 of them... but how would you do that? characters.antagonist, characters.neutral, characters.protagonist, characters.two_faced? or characters.mages?  it makes no sense unless your characters package is full of garbage and/or your character objects do not follow some patterns, then you will want to import only the relevant characters and not the garbage code, but that would be sign of a bad design.
Also why a package for states? isn't the state just an integer? does it require a whole package? do you really need to give insight about "there are antagonists in my game" by listing the packages? given that most computer games have antagonists... did you already code all those packages or you are just assuming they would look nice and straighforward that way, if they existed at all?
UPDATE: From your comments and the question edit I wanted to add some things.
There are some coding patterns that are common in game engines but the truth is you can't anticipate by using those patterns if you are not used to them/have experience enough with them, that's also why it's easier to start with a game instead of a game engine. In the package list from your question it's easy to notice that you're overengineering already, but you don't really know how will you code things in there (your package design is overly complicated for no reason).
You can represent most characters with a single class or so, it makes no sense to have such package/namespace distinctions, think about them as if they were an image/texture class, often you don't have pngimage, gifimage, tiffimage, bmpimage etc you just have image.load(), characters could be thought as a resource. They will share most attributes such as position or direction or AI algorithms, you may even want the player to be controlled by the AI at some point, or be able to control an enemy. It makes no sense to have another object for just one function--unless you're using a component architecture for complex game entities, but then they would be components, not characters.
I also disagree with the advice of hardcoding from Roy, you should never hardcode, because it will be harder, specially for an rpg, you have to find a scripting solution that lets you modify game states during runtime for character and item design, or you will be running the whole application every time you want to balance the stats of anything (at the point you will be spending more time running/compiling the app than anything else).
Of course if you must ship fast just put everything in a single file and pray, but otherwise take your time for doing it well.

The truth is that you shouldn't be making this decision at the beginning of a project. My rules of thumb (and trust me, this is very fast and loose) are:

Things which are obviously different concepts can/should go in different packages
try to minimize the number of packages you have to reference in any one class ... if you find yourself referencing every single package, you probably have a problem with the way you're expressing your classes. Remember, Single Responsibility Principle.
Don't be afraid to refactor ... this is the key point here. I usually keep things simple at first and keep everything in a single namespace/package. As the project grows and I find more than a screenful of classes in a single package, it's usually an indication that I may have to refactor.
Try to avoid deciding on patterns at the outset of a project. Favor working code first, and then as the codebase evolves, refactoring (common theme) to patterns that may emerge from your use cases.

At the end of the day, the most important thing is getting the game working, testable (for early/often playtests), and moving forward towards shipping. Note that I'm not advocating messy, or thoughtless code ... quite the opposite, there are patterns and stuff for a reason. But rarely can one decide those things up front, you will find yourself kludging what you're trying to do into a box, when you need a circle.
Now get out there, and make that game!

Do you do this with every project? I guess I'm somewhat surprised that there isn't a more repeatable process, or some acceptable patterns of organization, but I'm not a game programmer by trade so that could be the difference.

@Brian Reindel There really isn't any standard pattern for game development because every game is different.  There's basic techniques that work in all games, usually found as part of a library, but usually AI and states are specific to a single game.  Yes, there's exceptions (pathfinding libraries, for example), but there's nothing as strict as, say, the MVC pattern for games.

@Brian Reindel, the answer to that is yes and no :-) in this context, there are two types of game development programming: Writing a Game, and Writing an Engine. You should almost never write an engine if your goal is to produce a game. Now, once you've produced and released that game, if you want to make a sequel, or another similar game, then it makes sense to start restructuring into something more reusable. Now obviously, game engines are useful, but a game team should almost never be the one building one.

A single file to begin with, and split-out into separate files as/if required.


text:
When would I use "scripts" or "scripting" in a game, as opposed to the core language?
The terms scripts and scripting appear to be used interchangeably on the Game Development Stack Exchange, but other than reading questions about a scripting language choice, I don't understand the relationship between scripts and scripting, and the core language. What does a script typically do, when would it be used, and are scripts in some contexts (as defined by game programmers) different than a scripting language?

Possible dupe: http://gamedev.stackexchange.com/questions/2913/why-do-we-use-scripts-in-development

@Tetrad Thank you for the link, but I think the other question discusses more of the fundamental architecture question of "why", as opposed to for what and when.

"what" and "when" are going to be specific to your use cases.  The "why" gives you decision making abilities.  Without specifics, this question is a dupe (in my eyes).

Scripts are written for a scripting language. People can use the words in slang sentences to get the muddling that you are referring to but ask anyone for the definitions of Script, Scripting and Scripting Language and you will get something like: Scripting is the act of writing Scripts using a Scripting Language.
When you embed a scripting language into a game engine, or core language as you are referring to, you are exposing not only the objects within the game engine but also allowing logic to be written for the game engine. One other thing of note is that this turns your game into kind of a virtual machine, as scripting languages seldom compile down to machine language and are instead put into a form of byte code and interpreted at run time by your game engine.
This has some huge benefits to the development team, a few of which you can find listed next:

Scripting languages are usually memory managed so you do not have to worry about allocations
They are usually a loosely typed language that removes the need to make sure you are using the variable type for what you are doing, just make a variable and go with it.
The languages themselves are often very simplistic while delivering quite a bit of control to people who are not programmers
Altering scripts does not require the core engine to be recompiled.
Scripting vs Coding often reduces the time required for very iterative tuning of game logic.
Depending on design and language, you can often reload a script while the game is running for even easier tuning/testing.

I am sure the list can keep going on and on I am sure, especially when you get into specialized game types and how scripting can help define group formation rules for moving groups of units in an RTS or how you can create a UI's logic in a scripting language to provide an extensible UI to your end-users and the like.

Using scripting has many advantages over "core language". Some of these include:

Moving (more) of the content from core developers to artists, freeing the core developers to engine tasks from gameplay tasks
Scripts tend to be sandboxed, can't do anything really dangerous in it
Modifying scripts does not require recompilation and re-execution of the game

For your first bullet point can you provide an example of one piece of functionality that would be moved to a script for artists to edit?

@Brian Reindel Examples would be weapon/NPC stats, AI, and maps/levels.

Here's one example: In a strategy game with many units it is desirable for the designers to be able to define all the units in scripts that the core game then loads. Of course that may be accomplished with XML files rather than scripts, but it's the same idea.

@Hackworth Are you saying that AI programming is done by artists? The scripting that would be done by an Artist would include scripts for animations and rendering 3D objects and such.

Artists should not be made to program anything. You separate engine from game logic for the sake of modularity, not for the sake of offloading development to people whose strengths are elsewhere.

@Jon Purdy - my use of "artist" is a bit loose; I probably should have used some other term, like "level scripter" which is a form of programmer, but from a "core developer" point of view, they're in the artist (content) camp.

@Jari I'm not "up" on the jargon but I would use "level designer"/"world designer"/"Map designer" $0.02

@James well, the point is: they do "light" programming, but they're on the "content" camp. So terminology is tricky. =)

A script is usually a piece of code that runs outside your core engine. It is usually contained within text files wherever you like to keep them. Then it is usually loaded by the engine, parsed, and executed at runtime.
What generally happens is that whatever language you use (Lua, Angelscript for example), this language usually has some facilities that enable the engine programmer to expose engine-functions or even entire classes to the instance of the "scripting engine" that is currently running.
For example (totally stupid example, but just to get the point across) your game code might have a public function that spawns zombies somewhere:
void SpawnZombie(int x, int y, int hp /* whatever else */)
{
   //...
}

The scripting language that you use now enables you to expose this function to the scripting parser that is running. This effectively means that you can open a text file, write "SpawnZombie(200,300,1337)" and once your engine executes the code, a Zombie will spawn at that location.
The other answers already list a couple of good examples of how this is typicaly used, but they leave out one point which I find very important:
These kinds of scripts make it very easy to debug or test gameplay during runtime.
Let's say you want to figure out the perfect way to place a zombie in the map so it has the maximum scare effect on the player once they discover it. Without scripting support, you'd have to exit the application, change some magic numbers in the code, recompile and test it.
With scripting support (providing you already have some method of entering text during runtime, for example a debug console), you just type in "SpawnZombie(333,444,555)" and see how it looks.
In the same manner it could be possible for you to spawn weapons, vehicles, load different maps, change the values of some things in the game etc, instakill enemies because you don't want to waste time getting to the part that needs to be tested etc.
This will save you tons of times in more complex games.

1)  Scripts are often much easier to modify than code.
2)  Scripts are often field-modifiable.  This permits modding the game.

So would it be fair to say that your scripts then are built with languages that are not compiled so as to be editable by anyone?

@Brian Reindel: In general, yes.

Most scripting languages are a lot more expressive than the language in the core engine. Often the engine is written in a relatively low-level language (eg. C++) for performance reasons, but the gameplay code doesn't need to be as performant and so the priorities shift toward being able to express functionality easily.
For example, dynamic vs. static typing. Another example: garbage collection vs. manual memory management.

Scripting allow you to write logic at a higher level.  In other word, you write less code with more functionality.
So an example, the following shows the difference between writing something in code and writing it in a script language.
Game Code
Update Loop
{
    if (CarExplodeAnimation.FinalFrame == true)
    {
        SceneGraph.Remove(Car);
        Message("You have destroyed the car.";
    }
    else
    {
        CarExplodeAnimation.AdvanceToNextFrame();
    }

}
Script Code
PlayAnimation(ShipExplode)  // blocks until animation completes
Message("You have destoryed the car.")

See how much less coding the designer have to do if you use a scripting language?
The reason is becase in game code, you have to split an event into multiple frames, and write code from a multiple frames perspective.  On the other hand, scripting allow you to think of multiple frames event as a just a single line of code, because all the extra codes are abstracted behind an script function.
You may asked, but can't that function just be written in game code too?  Well, yes, but that means the designers will have to open the source code of the game engine and write all the codes in there, and you don't want your designers going through the source code of the game engine (they might accidentally change some other code and the whole thing crash).
Instead, you want your designer to do something like this instead:
Right-click a car in the Map Editor, click Insert Script, type in the script codes.  There's no messing with the critical game engine source codes.


text:
Should scripts interact with an abstraction of the engine?
I'm using Java and Jython, and after some research I discovered giving scripts direct access to the engine interface could be a mistake, as it would tightly couple the two.
It looks like most scripting that allows mods to create and manage entities does so through some sort of abstraction. Are these abstractions there for this reason, or is it just to provide a more intuitive way for non-programmers to mod the game?

Both, in general. Your scripts should talk to an abstracted -- or at least intermediate -- layer of functionality and not the engine itself.
First, this provides you an extra measure of control and security. It allows you to easily, cleanly define the interface a script is allowed to have with your game and thus what it can muck about with, as well as allowing you to place extra security checks in the intermediate later that would not necessarily be appropriate in the actual functionality layer itself.
Second, it allows you to simplify the interface exposed to scripts to be more non-programmer friendly or easier to use in general.
It does provide a bit of insulation against coupling between the two, but it's often not that big a deal because the scripts will always be coupled to the interfaces they are allowed to interact with, by their very nature. The other two points are far more beneficial.

I also think that it helps you in case you want to make modifications to the engine. You can do them without worrying about having to change all of your scripts since the engine changed. You just have to change the abstraction layer Josh mentioned.

Creating a layer between the core of the game and the scripts, used for creating modifications is, in my opinion, necessary.
You gain several advantages by using this method:
Easier for modders:
A good reason to do this is, as you mentioned, an easier ways to make mods. Writing less lines of code means more readability and minimizes understanding issues for programming newbies. Ideally, this API should be a collection of methods to change something on the game's high level. This means for example: Spawn an entity without knowing how it really gets spawned, or displaying an image with one call, which only takes the image name as a parameter.
You, as a programmer, also benefit from it, as you can write more in less time than you would need with Java.
Security:
Preventing people from controlling the whole game is essential. I would not care, if the game would be a single player title, but I would care when the game has got some multiplayer action. Even if it is only a highscore table.
Other people are always frustrated, when someone wins because of cheating (for example: position changes, more specific: position change and direct flag capping). To prevent players from doing so is your main task here.
Keep in mind, that the cheater can always decompile, change the code, recompile and play with this client, so add checks on server side. Generally, the "Security" provided is only another, not 100%-safe option to make life for cheaters harder.


text:
Random looking item placement that's deterministic?
I'm working on a sidescrolling game and I want to generate a forest for the background.  I want the background to be the same for every one to make sure the quality is the same.  I don't have access to a seeded random number generator either, so I can't find a good seed and go from there.
Ideas?

Why don't you have access to a seeded random number generator?

It's a game maker like program and it doesn't have one :(

What game maker doesn't offer a seeded random number generator? Weird.

Tagging it with the engine you're using would help us be more specific in the answers.

The most obvious way would probably be to write a random number generator of your own. Especially since you don't need to meet any particularly high standards for randomness (just lack of obviously visible patterns) it's pretty easy to write a pretty reasonable one in under a half dozen lines of code.
You can add a argument that make the object density abut the same to improve it if needed

This algorithm produces very good quality (as in "cryptographic" good) sets of random numbers (and even using 0 as your seed doesn't break it) -- it has been ported to many different languages (source included), and it's fast:  http://www.burtleburtle.net/bob/rand/isaacafa.html

Try this. Iterate from numbers 1 to n, where n is the number of trees you want to draw. Compute a hash on each number. Use the hash as input for the function that draws or positions the elements in the background. For instance, you could use the first 8 bits of a 128-bit MD5 hash as the x percentage, the next as the y percentage, the next as some sort of x scaling, etc. If you use the same hash function, and give the same inputs, each time you run it you will get the same output.
This should absolutely give both good randomness and will be deterministic.
Also, if this is not a good answer, please leave a comment explaining why.
Just looking at wikipedia, this method looks promising:
http://en.wikipedia.org/wiki/Random_number_generation#Computational_methods

I'm not the one downvoting it just trying to figure it out still :)

Thanks. Just a little frustrated how hard it is to earn 50 points so I can contribute comments...

This is rather high overhead (computing a secure hash function for each element) for something that would work fine with a PRNG. (I'm not downvoting you, just explaining why I don't think it's the best solution.)

Agreed. Perhaps it could be made more efficient to use a fast but bad hashing algorithm, and implement it as a bit stream so as not to waste any?

If you have access to any sort of hash (like MD5) or checksum (like CRC32), you could just hash a sequence of numbers.
Otherwise, the simplest PRNG would probably be the Linear Congruential Generator.  It has a complicated-sounding name, but writing one is extremely simple:
Choose three constants, m, a, and c.
Begin by setting xprev to your seed.
Then every time you want to generate a new value xnext, just do
xnext = (a*xprev + c) mod m
xprev = xnext
Some good choices for m, a, and c can be found here.

You could apply the cicada principle (use prime numbers for intervals).

Given that a seeded random number generated is essentially just a look up table with the seed being the offset (starting index), you can set up a simple one by reading in a CSV (comma seperated values) file of numbers.
As long as all instances use the same seed, it will be deterministic whilst maintaining it pseudo-randomness.

One possibility is to use an algorithm called simplex noise, invented by Ken Perlin (known for Perlin Noise). One nice feature of simplex noise (like Perlin noise) is that it can be tiled - ie, only a small region out of the potential area needs to be calculated and this can be repeated over the entire area without visible seams.

For the noise function to be repeatable, i.e. always yield the same value for a given input point,
  gradients need to be pseudo-random, not truly random. They need to have enough variation to  conceal the fact that the
  function is not truly random, but too much variation will cause
  unpredictable behaviour for the noise function

Simplex noise can be generated faster than Perlin noise and does not require a random number generator. It is not arbitrary to implement just by knowing the theory, but there is some source code to help you along (referenced from Wikipedia).
Other options for generating pseudo-random noise are fractals and wavelets.
On your situation you would use one of these techniques to generate a series of data in one dimension, and then apply a threshold to determine whether a tree should be placed at that position.

Simplest answer: Make your program load a file with pre-generated numbers in it and write a simple utility to generate random (or algorithmic in any case) numbers to save into that file.
In this way you can generate files that are mostly-good and hand tweak the remaining parts of it that suck without getting into the problem where every random seed you try has some problem with it.

I think this, coupled with any of the approaches given as answers for generating the numbers, is going to be the easiest for you to implement in the off-the-shelf engine you're using.

Another approach:
Use a block cipher to "encrypt" a series of numbers from 1 to N, using a fixed key. TEA is easy to implement and fairly fast.
One advantage of this approach is that if you don't like the series of "random" numbers which you get back, you can try a different encryption key and get a whole different series back.


text:
How do I implement SkyBox in xna 4.0 Reach Profile (for Windows Phone 7)?
I'm trying to Implement SkyBox in my phone game. Most of the samples in the web are for HiDef profile, and they are using custom effects (that not supported on Windows Phone). I've tried to follow this guide. But for some reason my SkyBox is not rendered.
This is my SkyBox class:
using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Rocuna.Core;
using Rocuna.GameEngine.Graphics;
using Rocuna.GameEngine.Graphics.Components;

namespace Rocuna.GameEngine.Extension.WP7.Graphics
{
    /// <summary>
    /// Sky box element for phone games.
    /// </summary>
    public class SkyBox : SkyBoxBase
    {
        /// <summary>
        /// Initializes a new instance of the <see cref="SkyBoxBase"/> class.
        /// </summary>
        /// <param name="game">The Game that the game component should be attached to.</param>
        public SkyBox(TextureCube cube, Game game)
            : base(game)
        {
            Cube = cube;
            CubeFaces = new Texture2D[6];
            PositionOffset = new Vector3(20, 20, 20);
            CreateGraphic(512);
            StripTexturesFromCube();
            InitializeData(Game.GraphicsDevice);
        }

        #region Properties

        /// <summary>
        /// Gets or sets the position offset.
        /// </summary>
        /// <value>
        /// The position offset.
        /// </value>
        public Vector3 PositionOffset { get; set; }

        /// <summary>
        /// Gets or sets the position.
        /// </summary>
        /// <value>
        /// The position.
        /// </value>
        public Vector3 Position { get; set; }

        /// <summary>
        /// Gets or sets the cube.
        /// </summary>
        /// <value>
        /// The cube.
        /// </value>
        public TextureCube Cube { get; set; }

        /// <summary>
        /// Gets or sets the pixel array.
        /// </summary>
        /// <value>
        /// The pixel array.
        /// </value>
        public Color[] PixelArray { get; set; }

        /// <summary>
        /// Gets or sets the cube faces.
        /// </summary>
        /// <value>
        /// The cube faces.
        /// </value>
        public Texture2D[] CubeFaces { get; set; }

        /// <summary>
        /// Gets or sets the vertex buffer.
        /// </summary>
        /// <value>
        /// The vertex buffer.
        /// </value>
        public VertexBuffer VertexBuffer { get; set; }

        /// <summary>
        /// Gets or sets the index buffer.
        /// </summary>
        /// <value>
        /// The index buffer.
        /// </value>
        public IndexBuffer IndexBuffer { get; set; }

        /// <summary>
        /// Gets or sets the effect.
        /// </summary>
        /// <value>
        /// The effect.
        /// </value>
        public BasicEffect Effect { get; set; }

        #endregion

        protected override void LoadContent()
        {
        }

        public override void Update(GameTime gameTime)
        {
            var camera = Game.GetService<GraphicManager>().CurrentCamera;
            this.Position = camera.Position + PositionOffset;
            base.Update(gameTime);
        }

        public override void Draw(GameTime gameTime)
        {
            DrawOrder = int.MaxValue;
            var graphics = Effect.GraphicsDevice;
            graphics.DepthStencilState = new DepthStencilState() { DepthBufferEnable = false };
            graphics.RasterizerState = new RasterizerState() { CullMode = CullMode.None };
            graphics.BlendState = new BlendState();
            graphics.SamplerStates[0] = SamplerState.AnisotropicClamp;

            graphics.SetVertexBuffer(VertexBuffer);
            graphics.Indices = IndexBuffer;

            Effect.Texture = CubeFaces[0];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 0, 2);

            Effect.Texture = CubeFaces[1];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 6, 2);

            Effect.Texture = CubeFaces[2];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 12, 2);

            Effect.Texture = CubeFaces[3];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 18, 2);

            Effect.Texture = CubeFaces[4];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 24, 2);

            Effect.Texture = CubeFaces[5];
            Effect.CurrentTechnique.Passes[0].Apply();
            graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, _vertices.Count, 30, 2);
            base.Draw(gameTime);
        }

        #region Fields

        private List<VertexPositionNormalTexture> _vertices = new List<VertexPositionNormalTexture>();

        private List<ushort> _indices = new List<ushort>();

        #endregion

        #region Private methods

        private void InitializeData(GraphicsDevice graphicsDevice)
        {
            VertexBuffer = new VertexBuffer(graphicsDevice, typeof(VertexPositionNormalTexture), _vertices.Count,
                BufferUsage.None);
            VertexBuffer.SetData<VertexPositionNormalTexture>(_vertices.ToArray());

            // Create an index buffer, and copy our index data into it.
            IndexBuffer = new IndexBuffer(graphicsDevice, typeof(ushort),
                                          _indices.Count, BufferUsage.None);

            IndexBuffer.SetData<ushort>(_indices.ToArray());

            // Create a BasicEffect, which will be used to render the primitive.
            Effect = new BasicEffect(graphicsDevice);

            Effect.TextureEnabled = true;

            Effect.EnableDefaultLighting();
        }

        private void CreateGraphic(float size)
        {
            Vector3[] normals = {
                                    Vector3.Right,
                                    Vector3.Left,
                                    Vector3.Up,
                                    Vector3.Down,
                                    Vector3.Backward,
                                    Vector3.Forward,
                                };
            Vector2[] textureCoordinates = {
                                               Vector2.One, Vector2.UnitY, Vector2.Zero, Vector2.UnitX,
                                               Vector2.Zero, Vector2.UnitX, Vector2.One, Vector2.UnitY,
                                               Vector2.Zero, Vector2.UnitX, Vector2.One, Vector2.UnitY,
                                               Vector2.Zero, Vector2.UnitX, Vector2.One, Vector2.UnitY,
                                               Vector2.UnitY, Vector2.Zero, Vector2.UnitX, Vector2.One,
                                               Vector2.UnitY, Vector2.Zero, Vector2.UnitX, Vector2.One,
                                           };
            var index = 0;
            foreach (var normal in normals)
            {
                var side1 = new Vector3(normal.Z, normal.X, normal.Y);
                var side2 = Vector3.Cross(normal, side1);

                AddIndex(CurrentVertex + 0);
                AddIndex(CurrentVertex + 1);
                AddIndex(CurrentVertex + 2);

                AddIndex(CurrentVertex + 0);
                AddIndex(CurrentVertex + 2);
                AddIndex(CurrentVertex + 3);

                AddVertex((normal - side1 - side2) * size / 2, normal, textureCoordinates[index++]);
                AddVertex((normal - side1 + side2) * size / 2, normal, textureCoordinates[index++]);
                AddVertex((normal + side1 + side2) * size / 2, normal, textureCoordinates[index++]);
                AddVertex((normal + side1 - side2) * size / 2, normal, textureCoordinates[index++]);
            }
        }

        protected void StripTexturesFromCube()
        {
            PixelArray = new Color[Cube.Size * Cube.Size];

            for (int s = 0; s < CubeFaces.Length; s++)
            {
                CubeFaces[s] = new Texture2D(Game.GraphicsDevice, Cube.Size, Cube.Size, false, SurfaceFormat.Color);
                switch (s)
                {
                    case 0:
                        Cube.GetData<Color>(CubeMapFace.PositiveX, PixelArray);
                        CubeFaces[s].SetData<Color>(PixelArray);
                        break;
                    case 1:
                        Cube.GetData(CubeMapFace.NegativeX, PixelArray);
                        CubeFaces[s].SetData(PixelArray);
                        break;
                    case 2:
                        Cube.GetData(CubeMapFace.PositiveY, PixelArray);
                        CubeFaces[s].SetData(PixelArray);
                        break;
                    case 3:
                        Cube.GetData(CubeMapFace.NegativeY, PixelArray);
                        CubeFaces[s].SetData(PixelArray);
                        break;
                    case 4:
                        Cube.GetData(CubeMapFace.PositiveZ, PixelArray);
                        CubeFaces[s].SetData(PixelArray);
                        break;
                    case 5:
                        Cube.GetData(CubeMapFace.NegativeZ, PixelArray);
                        CubeFaces[s].SetData(PixelArray);
                        break;
                }
            }
        }

        protected void AddVertex(Vector3 position, Vector3 normal, Vector2 textureCoordinates)
        {
            _vertices.Add(new VertexPositionNormalTexture(position, normal, textureCoordinates));
        }

        protected void AddIndex(int index)
        {
            if (index > ushort.MaxValue)
                throw new ArgumentOutOfRangeException("index");

            _indices.Add((ushort)index);
        }

        protected int CurrentVertex
        {
            get { return _vertices.Count; }
        }

        #endregion
    }
}

The first thing I do when stumped on graphics not displaying right is debug with the Pix application to see if they're being drawn at all. Then you can check if the problem is related to setting the vertexbuffer data, or the skybox has been transformed in a way that it's not visible on the screen.

Another issue with Reach profile, is that you can only use textures that are multiples of two for certain tranformations.  Depending on the error you are getting, ensure your texture is 2^n x 2^n

You don't have set View/Projection/World of the effect. Try something like this in the draw method :
        Effect.View = xxxx.m_viewMatrix;
        Effect.Projection = xxxx..m_projMatrix;
        Effect.World = Matrix.Identity;


text:
How to convert pixel coordinates to GL coordinates in 2D space?
I know that if you want to display a sprite on screen (in 2D) you can use glOrtho and essentially make 1 gl unit equal to 1 pixel, so when I plot out the vertices for say a 128x128 image (on a quad), I can define the vertices as -64/64, -64-64, etc and then when I map my texture coords to that quad, the image is displayed at a 1:1 ratio.
However, lets say I wanted to not use glOrtho and wanted to have a perspective view, so I can combine 2D sprites with 3D models and whatnot? I'm at a loss on how to convert/set up the coordinates for the planes/quads I want to draw images to, in a way that will match the resolution of the image. That is, define coordinates or convert them in such a way so that when a 2D sprite is right at the near plane, that sprite is mapped as 128x128 pixels on the screen.

completely off topic: have more self confidence!

(not big enough for a full answer, so I leave a comment) You can use two projections and draw your scene in two passes.  Just don't erase or flood fill the back buffer between passes.

This is easy enough to do. If it's not well answered when I get home from work, I'll do a big write up for you.

Nathans answer actually makes sense to me and it was what I was thinking all along, I just thought perhaps there was a better way. But please by all means do a big write up for me! lol the more information the better!

@Tetrad is it common on this particular stack exchange website to edit out parts of peoples questions because you simply think your edits look better? Just curious, because on all other stack exchange sites that I'm on I've never had someone cut up my posts for no apparent reason other than to to suit their own preferences.

@Ascension, it's a policy on SE sites to make questions more useful.  The parts I removed were irrelevant to the core of your question.  http://meta.stackexchange.com/questions/2950/should-hi-thanks-taglines-and-salutations-be-removed-from-posts

@Tetrad okay no problem. Just checking :)

You can calculate the size of the screen at the near plane by using a little trigonometry:
screen_width_in_world = 2.0 * tan(0.5 * horizontal_fov) * near_clip_distance
screen_height_in_world = 2.0 * tan(0.5 * vertical_fov) * near_clip_distance

That's the size in world coordinate units of the "window" on the near plane that represents the screen.  If you multiply those by 128 / screen_width_in_pixels or 128 / screen_height_in_pixels, you'll get the appropriate world space width and height for your sprite, to make it 128x128 at the near plane (and proportionally smaller as it gets further away).  This assumes the sprite is screen-facing.


text:
How to rotate blocks in tetris
I have a gameboard grid which is 20 rows high and 10 columns wide with the origin (0,0) being in the top left hand corner.
I have a tetrimino in play, which is composed of four blocks.
I have the x,y location of each block relative to the top left hand corner origin.
I also have the position of the pivot, the point around which I wish to rotate which is relative to the top left hand corner origin.
Each block has an integer position in a gameboard square and thus the pivot has a fractional position inbetween blocks e.g (10.5,10.5)
My question is: Which formula can I use to rotate each block around the pivot?
I have already looked at existing similar questions and answers but could not find an answer that I could get to work.
Help would be much appreciated.

belongs on game dev.

and if its here ... show us some data structure

If you're only rotating by multiples of right angles, then this should be fairly basic. Just draw a few diagrams, and you should be able to figure out an integer solution.

I wouldn't bother to actually calculate the rotations, simply put all four possible rotated versions in an array.

I would also suggest what @FredOverflow said. If you look at my question (which is similar to yours), you see how I stored a single block for my implementation.

The standard Tetris rotation logic is called Super Rotation System. SRS is suited to high-level Tetris play, allowing for many variations on wall kicks and t-spins.

All tetrominoes exist inside a bounding square and rotate about the center of this square unless obstructed. Tetrominoes of width 3 (J, L, S, T, Z) are placed in the top two rows of the bounding square and (for J, L, and T) with the flat side down. I is placed in the top middle row.
All tetrominoes spawn in 2 usually hidden rows at the top of the playfield. They are placed in the center of these rows, rounding to the left.
Once a tetromino lands, it does not lock until the lock delay expires. The lock delay behavior, called Infinity by the Tetris Company, resets the lock delay whenever the tetromino is moved or rotated. Hard drop is generally mapped to up, which has no lock delay.

There is another common variant called ARS, which was used in Arika's Tetris: The Grand Master games.

General formula for rotating around origin is
xNew = x * cos(a) - y * sin(a)
yNew = x * sin(a) + y * cos(a)

For 90 degrees it becomes
xNew = -y
yNew = x

So, firstly get brick center coordinates relatively to pivot point:
x = xBrickCenter - xPivot
y = yBrickCenter - yPivot

Then rotate them around pivot point:
x1 = -y = yPivot - yBrickCenter
y1 = x = xBrickCenter - xPivot

And then add pivot coordinates to rotated point:
newXBrickCenter = xPivot + x1 = xPivot + yPivot - yBrickCenter
newYBrickCenter = yPivot + y1 = yPivot - xPivot + xBrickCenter

But if you need to rotate by multiples of 90 degrees, you can store four sets of brick positions for each orientation and switch between them instead of actually rotating.

You could rotate all square rings (a-through-h by 2 positions, A-through-P by 4 positions, and so on) around that pivot block:

ABCDE    MNOPA
PabcF    LghaB
Oh.dG -> Kf.bC
NgfeH    JedcD
MLKJI    IHGFE

Follow the standard 2D rotation formulas in Mathematics should do your trick.
http://en.wikipedia.org/wiki/Rotation_(mathematics)#Matrix_algebra


text:
Is XNA for iOS overkill?
I'm working on iPAD game using MonoTouch which is similar to an IQ testing game. At the moment, I can write some simple games using basic UIImages and animations.
I'm wondering if I should learn XNA to create a game where people can throw a ball against a wall and see it bounce.
Has anyone seen any good examples of tutorials using XNA for simple 2d games?

There isn't "XNA for iOS". You can use MonoGame, an attempt to recreate the functionality of XNA under Mono. And yes, you can do a lot of things with it (if you stick to 2D games, they don't have 3D support yet); and you should use lower-level APIs like this if you are creating more complex, performance-demanding games.
Check MonoGame's site (previously linked) for examples of successful games published on iOS.

An alternative (also based on MonoTouch) is EXEN which I think is more widely used then MonoGame http://andrewrussell.net/exen/ (not sure though)

ExEn isn't being actively developed any more. That's a big bummer if you want long-term support and features.


text:
Is there a design flaw when an entity's state doesn't fully utilize enter(), execute() and exit()?
I'm following Mat Buckland's Programming Game AI by Example, and I find that I don't always have use for enter(), execute() and exit() on an entity's state. For example, in an RPG, a weapon may have an equipped state, and I may use enter() and exit() for that state to add or subtract to a player's ability modifier, but there isn't really a need for execute(). Is this a design flaw in my engine, or a shortcoming of this approach?

Not having read the book, those calls sound like normal entry points for a state machine. To understand the calls, let's look at what they do.
enter() - executed when the state is activated.
execute() - executed while the state is activated.
exit() - executed when the state is deactivated.
These fit any kind of state machine. Some machines only need the 'execute' calls, others need the 'enter' and 'exit', and still others need all the three.
Example 1: Machine gun trigger.

Execute: fire bullets at set rate.

Example 2: Force bridge

Enter: make bridge appear
Exit: make bridge disappear

Example 3: Personal power armor.

Enter: give player extra protection
Execute: drain batteries
Exit: remove extra protection

It's not necessarily a sign of any flaw.  Not every entity or state will have a use for every available method.  Just leaving the execute() method empty would be fine, IMO.


text:
Farseer engine built for MonoTouch?
Does anyone know where I can find a version of the farseer physics engine compiled for MonoTouch, or do most people just download a windows version from codeplex and attempt to build their own solution?

Did you ever figure this out? I'm also trying to include Farseer in a MonoTouch project, and I'm having loads of problems...

Farseer is based on Box2D.XNA, and looking in their repository, I'm seeing what looks like managed C++ (reference). I'm not familiar enough with managed C++ do know if it can be used to generate Mono-compatible .NET DLLs.
However, it looks like there's a native C# port of Box2D here. Just run it through MoMA and then try compiling it in MonoDevelop. I dunno if there's any compatibility scanner for MonoTouch, but last I read the main things you need to avoid are Reflection.Emit and unsafe code, and it's not likely those are used in this port of Box2D.


text:
Can the player character and static entities use behavior trees instead of state machines?
When I read discussions about state machines vs. behavior trees, it is often in favor of using one over the other. However, this seems odd to me that you wouldn't still need a state machine to manage the player character and static game entities (weapons, equipment, food, money, etc.). Do behavior trees translate to those concepts as well, even though they aren't technically AI?

as stated in wiki page behavior trees used in games are mostly something like a finite state machine. I'm not sure if there really is a need to define which one your AI is using since for games it's usually a combination of algorithms that gives the best answer.

A behavior tree is essentially a sub-type of a (possibly non-deterministic) state machine. Behavior trees are used not because they can do something FSMs can't, but because they are simpler to follow and understand for us humans.
Generally, AI has tons of states, and behavior trees are used to make them understandable. Other management, on the other hand, usually uses few states, and is perfectly clear even with most brain-dead FSM implementation.
If you, for some reason, have really complex behavior outside the AI - for example, you're making a game about alchemy, with tons of interlocked recipes, item properties, etc - using behavior trees instead of state-machines might be helpful.

Look at it like this, an enemy entity (clearly something in need of AI) is something that needs a behavior of some sort. We need this behavior to be conditional and not totally predictable. A behavior tree (with weighted-random chances when making a choice) is a good fit for something like this.
Now let's take a look at a gun. This clearly is not an item that is in need of a complex behavior, frankly I would not even suggest a (complex) state machine. All the gun needs is a few rules:

Trigger pulled + clip is not empty = fire bullet
Trigger pulled + clip is empty = make click sound
etc...

So that's basically how I see how someone could make an educated guess on what system best to use, of course there are always exceptions but always first try the simplest solution imaginable, often simple rules are the most fun (since people can understand them and mechanics do not become a black-box).

I like seeing "etc." there because that can cover the rare occurrence of a "mechanical error" (e.g., the firing mechanism jammed), defective ammunition (e.g., the bullet was a dud), etc.  +1 for a really good answer.

@RandolfRichardson tbh I haven't played a game that has that mechanic. I also said "of course there are always exceptions but always first try the simplest solution imaginable". And a mechanic that randomly breaks things or misfires things isn't a behavior tree at all. It's just a random chance per execution of a rule. Trigger pulled + clip not empty = fire bullet unless dud-roll > 5.