Starglider

Power consumption and price. I have an Acer Iconia Tab windows 7 tablet, battery life is fine, price was fine, the next generation will be better on both metrics. This is a PC game, it's supposed to run on real computers, not overgrown cellphones and stuff you got free with your breakfast cereal.

Just get an x86 tablet, Surface Pro or similar.

Sure but that's trivial on modern CPUs. The old IE games only had single-path problems due to lack of adequate CPU power. The problem that doesn't go away even with infinite CPU power is trying to fit multiple characters through a small gap. Naive single-entity pathing algorithms just do not handle this well even with hacks to try and fudge it. Most modern pathing problems are caused by characters blocking each other and screwing up the pathing, not due to inability to path through the static environment. I don't have this problem but then I play on watercooled overclocked bleeding edge machines. Note that the old engines were single threaded, whereas a new engine should use easily use four or more cores for game logic calculations.

If you are going to have classes, then there should be multiclassing, because the idea that once you chose a career you can learn nothing outside of that career is utterly stupid and unrealistic. Real humans can pick up a huge variety of skills in often surprising combinations. Dividing your attention makes you less well trained in any particular skill, but that is a choice for the individual to make. A mage being physically unable to practice fencing due to game designer fiat is a massive suspension of disbelief breaker.

2D backgrounds also take a substantial amount of technology risk out of the development plan, which is a good thing given the fairly tight budget and schedule.

I like having a combat-useless but scouting-excellent shapechange for this (for Druids or Mages). Bird, bat, fox, something like that.

Level disparity is not the issue so much as numbers/weaponry disparity. Random street thugs aren't going to be able to judge the difference between a 3rd level fighter and a 15th level fighter (in D&D terms). However two toughs with daggers aren't going to jump six adventurers with longswords, plate mail and obvious magical abilities. I am perfectly happy to have a gang of 20 thugs attack my late-game party and die within five seconds, because that's a credible mistake for them to make. However I wouldn't expect it to happen more than once per area.

After playing a game for 40+ hours I like to feel I've achieved something significant, even if there were major sacrifices made to reach the ultimate goal.

This is the most important point in this thread. Simple pathfinding failures are easily solved by brute force : modern CPUs can do path refreshes much more frequently and effectively have no path length limit. Making the party move realisically requires algorithmic changes; using actual motion control / formation logic and treating character motion as a joint optimisation problem, instead of just individual A* on each character.

Dev time is probably fairly low but the amount of QA needed would be huge. I would just leave some hooks in there so that it can be modded in easily by the community, that way we can have co-op functionality but Obsidian don't need to support it.

QA is the easiest bit of the team to scale. If you underestimated, you can either draft more testers or just outsource it to the many many global companies who provide contract software QA. I wouldn't be concerned about allocation at this stage.

Infinity engine games had no concept of height, but PE will definitely be modelling areas as 3D spaces (albeit prerendered). As such I would like to see holding higher ground as a meaingful choice in outdoor areas : also shooting down into enemy groups should be easier than trying to hit enemies standing up on battlements.

A mundane and believable backdrop makes the fantasy elements all the more impressive. This even holds for out-there settings like Planescape; the slums and slum dwellers felt authentic and grounded the wild and wonderful elements in reality.

Enemies that you can't normally beat are fine, but I don't see the harm in making it just possible for the hard-core mini-maxers to defeat the impossible encounter with hours and hours of research, failed attempts and grinding. It gives them lots of fun so why not? Encounters that must be unwinnable for story reasons probably shouldn't even have the option to start combat, or if you do it's instant cutscene death as in Lothar / PST.

The primary advantage of agile is coping with constantly changing requirements. This is less important on a video game where you basically have a spec up front, which you design, implement, integrate and test. The later part is usually more chaotic with features being added and dropped as the deadline looms, but still I would say it is much more waterfall than a typical business software consulting project where the client doesn't really know what they want. I have used many flavours of agile in enterprise software development but my Xbox 360 game (linked in my signature) was written with a purely waterfall process.

The classic spells : fireball, call lightning and (for when you absolutely positively have to kill every monster on the screen) meteor storm.

Nyet, nein, non, HELL NO. The internet is flooded with third-rate MMORPGs that no one plays as it is .

Half-Life 2 did this right with the antlions, which were more interesting than just 'oversized terrestial insect / arachnid'.

If you got into this situation it would be because the designers over-focused on the protagonist and failed to let the other party members behave realistically. If you need a specific skill, class, race or gender for a particular task you should be able to recruit a companion who can do the task for the group. Although wherever possible there should be multiple ways of solving each problem.

You can always pull maps, or chunks of maps from other 2D games and scale them to match. I'd be more concerned about the lighting and pathing systems, and how easy it is to get them running on modder-made maps.

Flashy finnishing moves are also helpful for putting together the game trailer.

Get a wireless mouse or touchpad. This is a game style that strongly benefits from a mouse, and for once let's not dumb it down for consoles. I say this as someone who actively develops Xbox 360 Indie Games.

I would be very surprised if the game wasn't unicode based, all modern engines and toolkits expect unicode strings.

As with the idea of a console port, make the main game for PC first, and if it's successful the ports can be considered seperately as low-risk self-funding propositions (even farmed out to another portfolio).

I have done extensive game AI programming and I can state confidently that this is not a significant limitation in 2D games. Back in the 1990s yes it was a struggle to get 100s of units in an RTS to act intelligently, but computing power is a complete non-issue for a few tens of actors on a modern multi-core multi-gigahertz machine. The problem is overwhelmingly algorithms, design and implementation; or test/dev man hours if you chose to try and solve the problem with a ton of unit and location specific scripting. The vast majority of real-time games including the classic infinity engine stuff do not use an 'all AI starts from scratch and completes on every single cycle' model. The basic engine executes simple actions set by both the player and the AI; the AI runs asynchronously and merely updates the current actions & targets from time to time the same way the human player does. A turn-based AI is still required to complete moves of individual units in a fraction of a second to avoid annoying players, that is not significantly more time than a real-time version (and with multi-core machines and all graphics done on the GPU, doing game and AI at the same time is not an issue). Again CPU time is not an issue for any algorithm you'd implement in this kind of game. Pathing (for example) is trivial in the first place for these relatively small and simple maps and not any harder for real-time since the path is only regenerated when the destination is changed or the path is blocked, not on every frame. No one uses chess-style deep lookahead to billions of gamestates in RPGs. No, it's because no one knows what calculations to do. Even full-time AI researchers with access to near-unlimited grid compute can't recreate human play ability in games as complex as Go, and the game state in Go is vastly simpler than the average RPG. A couple of hundred milliseconds is a relative eternity. Modern game engines draw hundreds of millions of polygons and shade several billion pixels in that time, as well as processing a couple dozen time steps on several thousand complex physics objects and a few thousand animated bones. Again, no one making these kind of games (turn based or not) uses algorithms that would lock up a modern PC for seconds. Maybe for Civilisation style games you might do that, but even there usually no, just heuristic analysis of a set of possible moves, no attempt to model player response. The limiting factor for AI in Infinity Engine games was primarily the amount of developer time available, secondly the very slow scripting engine, thirdly the limited engine support and least importantly the fact it had to run on late 90s CPUs. The last three should all be a non-factor now so it is almost entirely down to how good the programmers are (at writing game AI) and how much time they have to spend on it.