MReed

You raise two separate issues here: 1) "Games should attempt to implement the rules of P&P gaming systems or rules that could be implemented in P&P". This I don't see as particularly desirable, as there are abstractions required for P&P that can be eliminated in a CRPG. One obvious item is range increments -- in P&P, ranged weapons "to hit" chance is generally modified by whether or not the range to the target is "short", "medium", "long", or "extreme". In a CRPG, however, the modifiers should be applied at a much finer grain (say, every foot) and may take into account factors that aren't feasible in P&P (elevation, determining whether or not partial cover applies between the shooter and the target, and so forth). 2) "Games should attempt to eliminate abstractions that would require die rolls altogether, replacing them with realistic physics and collision detection." This is what I believe you were proposing, and I disagree strongly that this represent "progress". The idea here is that "If the player shoots a bow, they should indicate what direction they shoot in and how far back the pull the bow. The result should be determine by simulation the effects of physics to the arrow (air resistance and gravity being the two most obvious) and collision detection will determine if the arrow does any damage. For an example of the effects of the #2 philosophy, compare and contrast the mechanics of DA:O v. DA2 or ME1 -> ME2. #2 inevitably has the result of reducing the impact of character skills and replacing it with player skills -- whether or not the arrow hits depends on how accurately the player led the target rather than reflecting the skills of your character. This renders the concept of character skills largely irrelevant, and game play rapidly degenerates into standard action-based shooter / brawler type of gameplay. It also tends to eliminate active pause gameplay (as it makes it to easy -- Fallout 3 ran into this problem, based on what I've heard) and party-based gameplay (the value of multiple party members is dramatically reduced if their abilities are primarily determined by player skill). TL;DR: Removing abstractions that exist in P&P to save time can be a good thing -- removing abstractions that allow characters skill to be the primary factor in determining the results of individual actions is not a good thing.

Just for the record, I do not see this is an inevitable consequences of animination improvement -- and, more to the point, I don't see this as a good thing. If you see this as progress, then I'd suggest that you should be looking at a different company.

I know that you are looking for official word (and I'm interested as well), but since I'm seeing this thread for the first time, a couple of comments: As far as applications are concerned, hyperthreading = multiple cores. The application creates a thread, which is then assigned by the OS to a core, as far as I know without regards to whether it is a real CPU or a "virtual" CPU that created by hyperthreading. If I'm remembering correctly, hyperthreading allows a single core to start processing instruction X, then (once X has stopped using certain circuits) start the execution of Y, as long as instructions X and Y fall into some range of valid instructions. If instruction X and Y aren't hyperthreading compatible, then the core automatically blocks the execution of Y until X completes. Given that application programers don't generally have visibility into the machine language instructions that are generated when they issue a command, there is very little that an application developer can do to leverage hyperthreading beyond creating multiple threads and hoping that the OS does something intelligent with them. On multi-core processing within a single application: This is very, very hard to do. Even with a very well understood problem that has been worked on by hundreds of programmers, there finally exists an process that gets a speedup of 2x on 2 processors. Of course, on 16 processors the speedup drops to 11.1, and the implementation is so complex that most chess programs don't implement it... Cite: http://chessprogramming.wikispaces.com/Parallel+Search. Even an extraordinary game has a tiny fraction of the number of developers working on it than does the general group of "chess programmers", and those developers rarely have loads of experience in MPP development, so... Generally game programs that support multiple threads only support a couple -- a "graphics thread", a "sound thread", and a "game thread" -- and do a very, very poor job at distributing work evenly among those threads. So, one of three threads will be running at 100% utilization (say, the "graphics" thread), one thread will be running at 5% utilization (the "sound thread") and the other will be working at 20% (the "game thread"). As one might expect, this leads to only a marginal improvement in performance... Worse still, that marginal improvement comes at an enormous cost in development / debug time. That's because a multi-threaded game has loads of intermittent failure modes, that only occur when the "graphics thread" is execute instruction 95,483 at the same time as the "game thread" is executing instruction 38,283 -- in all other cases, everything works properly. Worse still, the failure might only occur when the debugger is not attached to the code, because the debugger itself is a thread itself and interacts with the other threads running on the computer at the same time. Speaking as a developer myself (not a game developer), trying to troubleshoot a bug without a debugger is an exercise in frustration. To sum up: Multi-threaded games generally only get marginal speedups at best at the cost of significantly increased development time and a very real risk of serious bugs only being discovered after release. This is why the vast majority of games don't support multiple threads. Note that the formula is a bit different if the underlying engine (Unity in this case) uses multiple threads internally. This is because the engine is (fingers crossed) well tested -- and is certainly better tested than any single game would be -- and the game can be developed as a single threaded application. This is one of the big advantages of using an off the shelf engine, and is the way that most "multi-threaded games" get the bullet point (the game itself is a single thread, but the engine has several threads, so there is some mutli-core activity going on).

You need to link your Kickstarter account to your website account -- once you've done that, your problem will go away. Since my account is already linked, I can't give you the exact procedure, but it was discussed in depth in one of the previous updates.

This probably isn't the game for you, then -- oddly enough, some people liked the Infinity Engine games, and (in particular) the elements that you are complaining about, so...

But the whole point of this thread is the Black Isle Studio stated, quite unequivocally, that is was illegal to distribute art assets from (say) IWD2 in a mod for BG2 -- and that's when both games were made by the same company. The underlying issue was that there wasn't (& isn't) any way to ensure that IWD2 assets are only used in a BG2 installation when both products are installed. There are a couple of potential technical solutions to this issue: 1) Modders can't use assets from one game in another, even though they are fully compatible, because of IP issues. This is pretty much the default position, obviously. 2) An official program is designed to install / uninstall mods in general, and this program would support an instruction that reads "Rather than installing this file from the files distributed with the mod, look for product X, extract this resource XYZ from there and place the asset here." This is what the OP is requesting. Under #2, the OP would also like either / both Obsidian and inXile to offer an "asset only" license, that doesn't include the game, but includes the assets in a form that the mod installer in #2 will recognize as valid -- this will allow people who are only interested in one title to install mods that require assets for the other without having to install both products. #2 would obviously require a significant amount of effort on the part of one or both companies -- given that neither of which has even agreed to provide mod support beyond "We'll document our file structure" this seems unlikely, at least at this point (I suspect that a final announcement of the level of mod support provided will not occur until the games are released, and will be based on how much funding is left over after implementing the game). And given that there are two separate companies involved, it really seems unlikely to me that they would be able to reach an agreement like this, but... Certainly nothing wrong with asking...

You are correct -- PS:T uses RTwP, and that's game was referenced in the previous post. However, the previous poster indicated that this game wasn't going to implement RTwP, and I have seen people confuse this title and Torment: Tides of the Numeneria, so I went ahead and covered both, just in case.

Gee, two confused people one one thread. Just to avoid spreading more misinformation: Pillars will feature RTwP gameplay that is very similar to BG2 / IWD -- obviously, the mechanics will be totally new, but you'll be viewing the action from an isometric PoV and will be able to pause the game at any time and give individual orders to each member of your party. Torment will be using a turn-based system of some description which will likely be somewhat similar to what is used in Wasteland 2. Neither game will feature NPCs that act on their own in combat, beyond (in Pillars) a fairly simple AI script that is adequate for battle clean-up in the like. If an AI script is provided in Pillars, though, you'll be able to turn it off altogether if you wish (and, for complex battles, you will probably want to do this).

I'm rather surprised that this is getting such a hostile reception. I don't particularly support it, and I suspect that the licensing issues would make this unfeasible to implement, it seems a reasonable request. There seem to be two major objections: 1) "I don't want Obsidian to try to 'save money' by levering art resources from inXile (or vice versa)": 2) "I don't want potential future modders to be able to leverage art resources from Torment in a Pillars mod (or vice versa)." #1 I agree with 100% -- but it worth pointing out that the OP that started all of this never even envisioned this use case... #2 I don't understand -- yes, obviously Torment and Pillars occur in very different worlds, but a simple wilderness area probably looks more or less identical in both, and I suspect that some interiors would have similar enough look and feel to "fit in" well enough. As the OP pointed out, several modders attempted to leverage IWD area artwork in BG2 mods, so there is certainly precedent for modders believing that artwork could be leveraged in this way. Given that we have been told flat-out that generating area artwork will likely be beyond the capabilities of most modders, and given that both games are using a common engine for area artwork....

There are only two things that I'd like to see Obsidian do in the way of mod support: * Release detailed documentation for all file formats used by the game, including links to documentation for "standard" stuff. * Develop and implement a "WeiDEU" equivalent for PE. For those who are unaware, WeiDEU is a "patching tool" for IE games that understands very well the formats used by these games, and can therefore do things that a simple binary patching tool can only dream of. For example, it can locate a standard conversation node (in a DLG file), insert a new option, attach a new script to that option, and can do all of this even if other mods have been installed at the same time (as long as the parent conversation node exists, of course -- but if the mod was developed on a computer where there were only 5 options available to start, but the end user has installed other mods that added two choices, your mod won't fail due to the fact that there are 7 options instead of 5. Similar functionality is available to add an NPC to an existing area, items to a shop or container, and so forth. WeiDEU is even smart enough to check to see if the parent /exists/ and branch based on whether or not it does or not -- this allows mods to detect one anothers presence, and install additional components if some other mod is installed. This is, for example, how the "Banter Packs" for BG1 and BG2 work with other mods: If you have mod X installed, and the banter pack supports mod X, then it will add banters for the new NPCs introduced in mod X if the user desires. If mod X isn't installed, though, no big deal -- you just wont have the option to install that content, and the rest of the installation will proceed normally. Developing WeiDEU was the thing that made the IE modding community feasible, far more than all of the editors and the like that exist. Prior to WeiDEU, the only way to mod the game was whole sale replacement of files (via the "Override" folder), which meant that if two mods needed to add a creature to an area they were incompatible without a significant amount of extra developer work. To be exact, the user would need to open the conflicting files up in an editor, identify the changes, then create a new override file that included both sets of changes and place /that/ file in the override folder. Integrating WeiDEU type functionality into the base game offers loads of advantages to any potential modding community: * A GUI can be integrated into the main game to install, uninstall, and view currently installed mods. * With a standard file format established from the get-go, it is far more likely that mods will be compatible with one another. * It should be fairly inexpensive to do.

Divinity: OS is a fully 3d game -- PE has 2d bitmapped backgrounds. While 2d backgrounds look better (generally speaking) than fully 3d worlds, it makes modding much, much, more difficult.

Hmmm... you may be correct, which would be disappointing if true -- it adds another strategic dimension to spell selection if there is a benefit in having the same spell in the grimoire more than once is beneficial.

Note that a simple 1/day or 1/encounter omits the second element of the equation -- you can equip grimoire's, which contain slots of spell levels. Nothing prevents you from putting the same spell into multiple slots, which turns it into a x/day or x/encounter (depending on level). I'm still a bit dubious about this spellcasting system, but I'm willing to see how it works -- I agree that the D&D version is implemented in BG has a big drawback where good roleplaying (not resting after every encounter) has a big impact on difficulty, and that's part of what this system is designed to address.

This is already promised. It is also totally irrelevant to the discussion at hand. Most people consider Stalin to be "evil", and unless I'm missing something, the "Real World" [pretty good game actually, but it really needs a better saving system ] doesn't include character sheets at all. How, I wonder, are people able to make this judgement without an explicit alignment indicator?

And this is why people oppose multi-player. I wouldn't have backed a game that included any one of these elements -- I would be very, very, dubious about buying a completed game that included most / all of these elements. Yes, there are people who would be 100% satisfied with BG2-style multi-player, and this wouldn't bother me in the slightest, but there are also people like Karkarov, who would like to see core gameplay elements modified to improve the support of multiplayer. If any sort of multiplayer is introduced, then folks like Karkaprov will quickly dominate the discussion of what features need to be included in future titles, and we will end up with a DA:O -> DA2 -> DAI type of situation. I don't want to see this happen, and therefore I feel obliged to oppose multiplayer in any form, even in the BG2 form, to minimize the chance that this occurs.

I'm shocked that Legend of Grimrock sold that many copies -- but... I just checked, and it is currently priced at $15 on Stream (not on sale). My sales guesstimates were based on a ~$50-$60 price (the slacker backer price is currently $35, so I'd expect the retail price to be in this range). Lowering the price will obviously increase sales, but still -- 600k @ $15 = $9 M in gross, which would be a tremendous success for this game, earning its investment several times over. Still, I have a hard time expecting sales at this level, simply on the basis that the publishers can't be that bad at making business decisions. Yes, they are mostly interested in games that gross $100M+, but still... Fingers crossed, though -- PE2 should be /really/ impressive is PE can run up sales figures in that range!

Note that no level of access will allow you to play it today -- the game isn't anywhere near complete enough to allow backers to play. But purchasing beta access will allow you to play a (incomplete, likely buggy) version of the game some time (likely 2-5 months) prior to the retail release.

I'm 100 % in favor of corruption / redemption arcs (more generally, "world-view changes") for some and only when appropriate companions and other NPCs, as that is one of the most effective ways of supporting "good" / "evil" playthroughs. However... As has been pointed out, there is likely to be a realism problem due to the (perceived from the players perspective) short timespan of the game, which is hard for the developers to address. And there are several other problems as well: * If the companion / NPCs world-view only changes at the very end of the game it largely defeats the purpose as far as I'm concerned. There are good reasons to do it this way -- having a major world-view change 1/3rd of the way through the game means that the developers have to develop (in effect) an extra 2/3rds of an NPC (at least, as far as writing is concerned -- and that's the bulk of the expense for a companion or NPC).. And the earlier such a transition occurs, the less realistic that the transition feels to the player, which is already a problem. * It is very, very difficult to inflect negative consequences on the player (especially the loss of a companion, but also covers loss of quest opportunities, stat points, and so forth) due to pursuing an arc of this sort. That's because you are, in effect, providing a mechanical punishment or reward for what really should be driven exclusively by roleplaying considerations. This makes balancing these arcs very problematic. In short, maybe the best solution is to simply let the player / protagonist "trick' companions or NPCs into performing actions that conflict with their world-view /and punish the player if the deception is ever revealed/. This allows players the same roleplaying opportunities as a redemption / corruption arc provides, but eliminates the need to actually change the dialog of the companion or NPC. As far as I know, nothing along these lines has been tried in the past, but it certainly sounds intriguing....

And then it will take a week for the request to make "minor changes" in the sequel to make it work better with controllers...

There is a big difference between "commercial success" and "profitable". To be exact, to be a commercial success a game (or anything else, for that matter) needs to earn enough to provide a return on investment -- and the investment in this case is somewhere north of $4 million. Yes, due to the unique funding model offered by Kickstarter, Obsidian is in the very nice position of not having to pay back its investors, but from the POV of "industry observers" and publishers who might finance future titles along the same lines will be judging the success or failure of the game by that standard. Of course, to be fair you should count contributors who receive a copy of the game as "pre-orders" at the minimum cost to purchase a copy at the point when the backed the game (regardless of the actual contribution level). This helps moving the needle, perhaps quite a bit depending on how many retail sales there are, but... Not that far, I'm afraid. I admit that I'd be curious to see the final numbers -- actual costs incurred v. revenue received -- but I suspect that Obsidian can't (legally) or won't ("trade secrets") release that kind of detailed data publicly. After all, Obsidian is an ongoing business concern and has to take that into account when making decisions to release this kind of data.

All of you guys seem to be missing the fact that this game will be launching about the same time the Steam Box starts rolling out to full release. A shiny "Project Eternity, Big Screen, Full Controller Support" icon on it's sales page sure would do wonders for the games sales at that point. But maybe they don't really care about sales they get after the kickstarter. I also really don't understand the hostility a lot of PC gamers have towards controllers. I am a PC gamer myself. I don't even intend to buy either of these next gen systems, but I enjoy playing games w/ a controller that allow me to lean back in my chair and prop my feet up. I don't understand how a pause-based strategic RPG is not the ideal kind of game for this play style. It's not a twitch FPS game where you have to hover over the screen for pixel precise kills in split seconds. I'll be playing the game regardless, but I know a good number of friends that won't even have that option since they play all their PC games on a TV now and certainly they are alienating themselves from the SteamBox base. For the little amount of work this would take, it just seem really lacking in forsight not to include this feature when a huge PC push that is all about big screen play is coming out the same damn time as this game. You are totally missing the point of both this game and Kickstarters for video game's in general: You are 100% correct that making the game controller failure would dramatically improve sales. I mean, even a bad port would likely double, if not triples sales. Additional obvious adjustments to increase sales would be to include multiplayer support, full voice over, adding "action-iy" elements, such as full 3D + 3rd person POV.. I don't think anyone here would debate this, including Obsidian. But... If that was the game that Obsidion wanted to make, there never would have been a Kickstarter. It is highly probable that some publisher would have been more than willing to finance the development of the game, probably to the tune of $15-20 million. The goal of the Kickstarter is to make a game that will not be a commercial success, or at least, seems very unlikely to be a commercial success. In this case, it means making a PC exclusive game with no multiplayer support, no voice over, fixed isometric point-of-view, and so forth. Inevitably, the consequences of these decisions, along with the fact that a good portion of their sales have already occurred means that relatively few units will be sold at retail. I'd be very surprised (& pleased!) if this game breaks $1 million (20k sales) in revenue, and feel $250k (5k sales), And that's fine, because even if it doesn't sell a single unit Obsidian breaks even (theoretically, at least -- given game development budgets, I suspect an overrun is likely). Now, if it turns out that the Stream controller and Streambox allow this game to be played in the living room, then... I have absolutely no objection to it. If that's how you enjoy playing your PC games, more power to you. But as soon as Obsidion spends even one second considering "Gee, if we changed this it would work much better on the StreamBox / with the Stream controller", then I object -- violently.

we're talking about pre-rendered pictures as backgrounds. while you can spend thousands of dollars for professional apps you could also simply use blender to create the needed render outputs. it's totally free and in no way behind the expensive tools. Obviously, but it won't be that simple -- as you pointed out, creating walkmeshes isn't feasible without non-free tools. But, in any case, my point isn't that there aren't free tools available that could be used to create mods, just that this isn't how Obsidian is doing it, and that it is unreasonable to expect them to research and document a mechanism for creating (say) area maps that they aren't going to use. That's OK -- as long as they provide the details of the file formats and so forth, I'm quite confident that the community will put together the required documentation within 3-4 months -- assuming, of course, that the game is good enough to create a demand.

Osvir, you are interpreting the message almost correctly -- what he is saying is that the average user, on day 1, won't be able to mod the game. However, there are likely to be a population of above average users who, with Obsidian's active assistance, will be able to write tools to enable a larger audience to mod the game. Given that this happens even when the developers don't provide assistance (and, in some cases, actually make it harder to do -- say, by encrypting files), this is a fairly good assumption. And there is at least a hope that Obsidian will release the source code for the tools that they used to make the game -- this has never happened before, due to IP concerns, but given the lack of a publisher for this game it is at least possible.

There are two answers to this question, depending on how you want to look at it: The first answer is "Yes, of course you'll be able to do this -- after all, people can do this for BG1 / BG2 and so forth -- unless a game is a console release, it is almost always possible to mod the game". The second answer is "...But Obsidian can't release the tools that THEY used to do it, because these tools are plug-ins for tools that cost hundreds or thousands of dollars per instance (e.g. "3DMax"), and even they spent the development time to create 'crippled' versions of these tools [that could only create environments for PE, for example -- see NWN 1 and 2) they would still have to pay significant license fees to the vendors of these products before they could distribute them for free." In addition, the tools aren't built to the same standard as the game itself -- if it randomly crashes every 6 hours, or only works with one particular 3d accelerator, that isn't an issue, because the only people who are going to use it are a few dozen area designers and the like. The Q&A of putting these tools into something that is stable enough to release is not insignificant. Given the small budget for this title, the odds are very high that what Obsidian will do is release file format information/ details of what commercial products that they used / *perhaps* the plug-ins they developed for these tools and leave it up to the fan community to build the actual applications that can be used by non-technical fans to mod the game. This is pretty standard for modding communities for numerous titles, most notably the Infinity Engine games. Another option would be to hold a separate kickstarter /just/ for mod tools -- but the target would likely be $500k - $1M, and it seems unlikely that such a number is achievable unless the game is /really/ popular.

I'm missing my kickstarter badge as well.