[[3.0] Startup crashes]

The game was crashing at startup today, after playing the game with no problems yesterday (no computer restart or major changes in between). The crashes stopped after I restarted Steam, and I haven't been able to reproduce. I've included the dumps and my dxdiag info in case you find something.

dumps.zip

DxDiag.txt

[Suggestion - Borderless Fullscreen as an option]

However if the solution isn't coded into the game it won't be available for the hard copy or GOG version.

 

I have this problem with Expeditions: Conquistador and the audio fix. It works as a steam startup command but I have the gog version, so gg.

Adding a launch option in Steam only makes Steam pass a command line argument to the game. You can do the same thing by adding -popupwindow to a shortcut pointing to PoE's executable.

 

But an in-game option is obviously the best.

[The B word]

 

I actually just posted something that would fit in very well as a response to this here: http://forums.obsidian.net/topic/67467-no-bad-builds-a-failure-in-practice/?p=1492653

 

TL;DR - I agree. "No bad builds" doesn't mean "less fun because easy", it means "more playstyle options". At least if done right - and that's what we Beta testers are for.

I do agree with you. The problem if you want to call it that comes down to some players perception of it.

 

I've posted this in other forums for ARPGs such as D3. I think a lot of players get caught up in a "Viable" vs "Efficiency" dilemma.

 

Group 1 views it as such...

Viable = Can complete all content

Efficiency = Doing the content the fastest/most optimal

This group tends to be ok with varied time/effort put into achieving said goal....not to say they would be ok with option A taking an hour longer than option B....but they can live with "less than optimal" play as long as it can finish the task within a "reasonable" time frame.

 

Group 2

Viable = Efficiency

If option A isn't as efficient as option B...then option A isn't viable and hence the game is imbalanced.

 

I guess my point behind this is this seems to be where the real argument is hiding within and depending on which group you fall into...makes the attribute system look quite different.

 

Power gaming can be fun but appears to be a sickness for some people.

 

 

Whether you use PoE's system or a more D&D-like system, power gamers will still do their thing, so we can safely ignore them.

 

In terms of game design, the problem of balance can be approached, I think, from two axes.

 

The first axis concerns equality vs. equivalence. Some view balance as being something where everything is equal, i.e. no class does more dps than another, no build does more dps than the other, and the differences only affect non-mechanical or story aspects. Others view balance as equivalence: while one class might do more dps, another will provide more utility, and while some particular build might be weak in some areas, they will be strong in others. Most RPGs tend towards equivalence due to the number of different kinds of abilities that cannot directly be compared against each other.

 

PoE is no different. In fact, since it is a story-based singleplayer-only RPG, it could do with even more divergence here. I think the devs focus too much on combat balance as opposed to overall balance. For example, providing some optional abilities for Fighters that can counter spellcasters is good, but making it so a group of generic Fighters can take on a balanced party is bad. In a group of only Fighters, some should be required to specialize in dealing with spellcasters, some with ranged attackers, etc. in order for that group to even be able to scratch a balanced party. And making those different possible builds equivalent in utility and power is good, but making them equally good overall is bad.

 

The second axis is about symmetry vs asymmetry. In every RPG, there's a needed amount of asymmetry required as you introduce classes. Another source of asymmetry is usually the character stats. This is not the case in PoE though, where every stat affects every class in the same way. Personnally, I think having more asymmetry is better. But that doesn't mean you need to make stats only affect certainly classes or types of abilities. The only problem I have with the character stats in PoE is that they affect all classes in the same way. If stats affected classes in different ways, I think it would make for better build variations.

 

For example, maybe intelligence gives AOE to all clases, but for Wizards it also gives more spells and for Fighters it gives a bonus to attacks of opportunity or even simply a small overall bonus to all combat rolls (a more intelligent fighter is overall better than a dumber one). And maybe some stats give no direct advantage to certain classes. For example, Might is utterly useless for a Wizard as far as his Wizard abilities are concerned, but a strong wizard can fight better in close quarters and can carry more **** (so you might want to introduce actual significant weight for multiple grimoires, scrolls, potions, and maybe even spellcasting materials). Wizards that can unleash godlike spells while naked are all well and good, but there's no reason while it needs to be that way. So maybe Might/Dexterity changes how armor influence spell failure. So a beefy, highly dextrous Wizards might be able to cast spell relatively well from inside full plate armor. This way you could use touch-based spell more safely, or you could use defensive spells to tank up and let your Rogues backstab everyone, etc.

[How can they solve the massive texture problems?]

As long as PE doesn't have textures popping up/loading slow all the time.

 

There was no texture popping in RAGE on the consoles, even though they are not as fast as modern computers. Why? Because you don't have the graphics driver + Windows overhead. Plus, the Unreal 3 engine has a similar texture problem on some configurations and it doesn't even use megatextures.

 

Since the backgrounds are 2D and the maps are loaded completely (I assume) before being displayed, there shouldn't be a problem here.

[Future proofing the engine]

Dude, I'm already using Unity 4, there is a beta available for pre-orders. I can tell you there is no differences on multiplayer side.

 

And we all know beta software is exactly the same as release software.

 

In any case, it doesn't change the need for future proofing. If you're right, in fact, it would make future proofing even more important.

[Future proofing the engine]

Guys, none of you actually get what I'm saying. I'm not saying "add mod support" and "add multiplayer". I'm saying "design the game so that multiplayer and modding support is easier to implement later down the road".

 

And as far as I know, no one on the dev team said they were going to officially support modding, for example by releasing their tools. Any game can be modded if you make your own tools or in this case by using the Unity tools (as long as they don't modifiy the engine too much). But being able to mod a game doesn't mean the game supports modding. The old Infinity engine is a case in point.

 

As for the complexity of adding a functioning multiplayer to the Unity engine, the game will use Unity 4 - which isn't released yet - so unless you've had access to it before everyone else I don't think anyone can tell how hard it would be to make the multiplayer side of thing work.

[Future proofing the engine]

I was just reading a thread about adding a replay functionality to the game and it made me think about future proofing. The devs have said that multiplayer will not be included in Project: Eternity, but we all know that the Unity engine already includes all the necessary code for it. Modding support is also up in the air. So why not future proof the game by designing every feature/change with future network functionality and modding in mind? Since the devs will be learning the Unity engine from scratch anyway, why not do it right the first time?

 

So that's the first thought. Next, I remembered that Valve recently modified their replay file format for Dota 2. Instead of whatever method they used previously in the Source engine for making demos, they now encode all RPC, etc. in a protobuf file. The good thing about Protocol Buffers, as Google themselves say, is that it's as extensible as it is efficient. Now, I'm no specialist, but I would think that this would make version proofing saved games (and replays, if implemented) much easier. And version proofing is a big part of future proofing. It's also a big part of modding support.

 

So what do you think?

 

edit: link to the replay thread.