Jump to content

Recommended Posts

I'm a bit concerned with how much work there is still do and only about 8 months to do it in. Pre-Alpha > Alpha > Beta > Full game shipped. Novella, Almanac, Physical Tier rewards, printing Books, etc. It seems like a short time to do all this. Have you been sourcing suppliers for the physical tier rewards as well? eg. looking into what InXile is doing?

 

Fulfillment/distribution of physical goods has been on our radar from the beginning of the Kickstarter campaign.  As game developers, we'd rather not be a fulfillment house.  We've seen other companies nobly struggle with order fulfillment and practically drown in their own success, so we've been talking to other companies about that for a while.  Even if we could technically handle it ourselves, it would be an inefficient use of money.  We assume our backers want us fixing bugs and polishing content instead of packing boxes and printing out shipping labels.

  • Like 14
Link to comment
Share on other sites

Now I have visions of die-hard RPG fans dusting their shipping labels to see if they can identify which developer's fingerprints are on it...

 

:p

  • Like 1

I cannot - yet I must. How do you calculate that? At what point on the graph do "must" and "cannot" meet? Yet I must - but I cannot! ~ Ro-Man

Link to comment
Share on other sites

Is a pistol considered a primary weapon in this game, or would that be more of a situational-use weapon?  Would you handicap your character too much if you chose skills allowing you the use of both a pistol for ranged, and a melee weapon for CC?  Is that even possible?

Edited by Chaos Theory
Link to comment
Share on other sites

Pistols can be primary weapons.  They are the fastest-reloading but least damaging firearms.

Other question.

Can we get firearm/melee weapons? The obvious implementation of this is bayonets, but several Renaissance gunsmiths thought nailing guns onto maces or whatever would be cool, and thus created things that neither worked as guns nor as maces.

Link to comment
Share on other sites

Do spells scale in power with level? I assume no since, afaik, spells eventually go from per day, to per encounter, to at will. Also increasing in power would seem a bit OP.

I second this question, because it's a darned good question.

 

As for the rest, you could still have them scale a bit. I mean, if a PewPewLezzerBeam spell does 5 damage at the start of the game, and 20 hours in, almost everything has at least 4 armor and that spell still only does 5 damage, it's kinda moot that it's now at-will as compared to the per-rest that it once was. It could just scale at a lesser rate than other spells.

 

Basically, it can scale only to stay not-useless, but not scale so much that its damage X its at-will usage rate = OP.

Should we not start with some Ipelagos, or at least some Greater Ipelagos, before tackling a named Arch Ipelago? 6_u

Link to comment
Share on other sites

Other question.

Can we get firearm/melee weapons? The obvious implementation of this is bayonets, but several Renaissance gunsmiths thought nailing guns onto maces or whatever would be cool, and thus created things that neither worked as guns nor as maces.

 

I like the cinematic idea of Sharpe's Eagle-style smacking or stabbing folks with rifles but there are a lot of interface/implementation problems with it.  Sorry.

Link to comment
Share on other sites

 

Other question.

Can we get firearm/melee weapons? The obvious implementation of this is bayonets, but several Renaissance gunsmiths thought nailing guns onto maces or whatever would be cool, and thus created things that neither worked as guns nor as maces.

 

I like the cinematic idea of Sharpe's Eagle-style smacking or stabbing folks with rifles but there are a lot of interface/implementation problems with it.  Sorry.

 

Really? Do the problems specifically stem from the fact that it's a gun? Because in the IE games you had stuff like magical throwing hammers/axes that you could choose to wield as melee weapons or ranged weapons depending on which option you clicked on in the weapon's "abilities" screen.

 

 

Anyway, I have a question. Is Unarmed combat included in one of the categories that fighters can specialize in?

Edited by Stun
  • Like 1
Link to comment
Share on other sites

I am enjoying this new trend we are seeing on some websites where the developers are prepared to answer certain questions directly through threads like this. It really allows you to identify with people on a personal level and expeditiously get relevant feedback , yes you can argue that PoE is fan funded so there is a greater expectation from fans of more interaction but many KS campaigns just rely on KS updates to get there message across. So good effort Obsidian :)

 

Of course I imagine the negative to this type of communication is the deluge of questions a particular person may receive and maybe how people expect an answer. But I think this has  been managed well

  • Like 3

"Abashed the devil stood and felt how awful goodness is and saw Virtue in her shape how lovely: and pined his loss”

John Milton 

"We don't stop playing because we grow old; we grow old because we stop playing.” -  George Bernard Shaw

"What counts in life is not the mere fact that we have lived. It is what difference we have made to the lives of others that will determine the significance of the life we lead" - Nelson Mandela

 

 

Link to comment
Share on other sites

 

This is sort of a dumb question because i have no idea about programming, but since you're a programmer and answering questions...

About 2 years ago i read on a different forum that C# might replace C++ in popularity soon for working on more processor heavy software. Coincidentally I read recently that Unity uses C#, so i'm wondering do you think that that might be the case as well, and if it is what do you think is the reason for it?

 

I haven't read that. If I had to speculate on why someone would say that, I could think of a few reasons. First, C# has some fancy multithreaded things like concurrent collections and parallel loops that are built in and don't require a library. It's pretty easy to make your program take advantage of multicore/cpu machines. Secondly, C#, like Java, uses a runtime framework that theoretically can run better on a variety of hardware.

 

Line-for-line C++ is always faster than C#.

 

 

C++ is not faster than C#. They're languages. Code compiled to native CPU machine language is faster than run-time compiled byte code.

Link to comment
Share on other sites

C++ is not faster than C#. They're languages. Code compiled to native CPU machine language is faster than run-time compiled byte code.

One road isn't "faster" than another road of the same length, either. They're roads. But, when you're always accounting for roughly the same amount of traffic in an area whenever you take a trip to your destination (such as having to go to work, during business-hour traffic), people often say "Route X is always faster."

 

What they really mean is, "with all the factors you're going to have to deal with in both routes, Route X typically has factor values that allow you to get to your destination sooner than if you had taken the other route."

Should we not start with some Ipelagos, or at least some Greater Ipelagos, before tackling a named Arch Ipelago? 6_u

Link to comment
Share on other sites

 

C++ is not faster than C#. They're languages. Code compiled to native CPU machine language is faster than run-time compiled byte code.

One road isn't "faster" than another road of the same length, either. They're roads. But, when you're always accounting for roughly the same amount of traffic in an area whenever you take a trip to your destination (such as having to go to work, during business-hour traffic), people often say "Route X is always faster."

 

What they really mean is, "with all the factors you're going to have to deal with in both routes, Route X typically has factor values that allow you to get to your destination sooner than if you had taken the other route."

 

 

I'm not sure what you're trying to prove. A program compiled to native CPU instructions is always faster than the same program compiled to byte code. The programming language is irrelevant. BASIC, Lua, C#, C, Java, Fortran, C++ -- it doesn't matter what it's written in if the end result is an executable in native CPU instructions. The BASIC compiler I used in college produced executables every bit as fast as the C compiler I used.

 

Anyway, glad to bump the post, there's a lot of good information from the devs here...

Link to comment
Share on other sites

 

 

C++ is not faster than C#. They're languages. Code compiled to native CPU machine language is faster than run-time compiled byte code.

One road isn't "faster" than another road of the same length, either. They're roads. But, when you're always accounting for roughly the same amount of traffic in an area whenever you take a trip to your destination (such as having to go to work, during business-hour traffic), people often say "Route X is always faster."

 

What they really mean is, "with all the factors you're going to have to deal with in both routes, Route X typically has factor values that allow you to get to your destination sooner than if you had taken the other route."

 

 

I'm not sure what you're trying to prove. A program compiled to native CPU instructions is always faster than the same program compiled to byte code. The programming language is irrelevant. BASIC, Lua, C#, C, Java, Fortran, C++ -- it doesn't matter what it's written in if the end result is an executable in native CPU instructions. The BASIC compiler I used in college produced executables every bit as fast as the C compiler I used.

 

Anyway, glad to bump the post, there's a lot of good information from the devs here...

 

 

Some native code compilers produce faster (better optimized)  code than some other native code compilers, and efficiency difference between compilers only rises when complexity of compiled code rises. As popular programming languages have more compilers and more money put in researching and developing said compilers, they usually have usually compilers that produce faster running code. Although programming languages aren't equal in way they are designed, for example C++ is designed to be more high level programming language than C and therefore programmer using it needs to know less about hardware that will run code than what C programmer, but this also means that its compilers can't always produce as highly optimized binary as what C compilers can produce, which mean that in most times code that is written with C runs faster than code that is written C++, but C++ code is easier to move to another platform/processor/chip than what C code.

 

So at the end it matters what programming language you use, even if code is compiled to binary, as there is differences between what languages are designed to do and how optimized compilers there is for platform that you are writing code for.  

  • Like 1
Link to comment
Share on other sites

It's really cool to read this Topic.

Tx.

★ ★ ★ ★ ★ ★ ★ ★ ★ I ' M ★  ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ B L A C K S T A R   ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ ★ 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...