• We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
If there is one thing that made absolutely no sense in 2.0 it would be the inability to assign a ruler as the leader of a legion.

It is absolutely vital for a nation like Epirus and even beyond that some people really like it for roleplay purposes.

I think Arheo hinted that this might change so let's hope it will happen soon.
 
  • 5Like
  • 3
Reactions:
But how would we balance this map painting single player game for competitive MMORPG rules if you can appoint a ruler to command a legion and get loyalty of it? Reeeeeeee! It's almost like you can have many legions and can command one would balance it out.
 
  • 2
  • 1Haha
Reactions:
A ruler could govern the capital region and lead a legion halfway accross the world just fine in the past. And he can already lead multiple levy armies at the same time. Why is one more so bad?
 
It's a clear sign that they don't test the game before patches... They would have been aware of this problem the moment one of them actually played with a monarchy. I was going to play a Epirus campaign after I finish the current one, but seeing this, I better wait.
It's a clear sign they should be doing betas for their very complex grand strategy games because the community would quickly catch all these problems.
 
  • 1
Reactions:
It's a clear sign they should be doing betas for their very complex grand strategy games because the community would quickly catch all these problems.
Seems you have inside info. What would you cut down on to fund the beta release, administration of beta testing and post beta development sprint?
 
  • 1
  • 1Like
Reactions:
Seems you have inside info. What would you cut down on to fund the beta release, administration of beta testing and post beta development sprint?
Huh? Why would a beta release require extensive repurposing of funds? Releasing opt-in preview or test builds that the devs are currently working on for community feedback isn't exactly an arduous extra step, and is something other much smaller devs (and Paradox itself in other games) do all the time without an issue. In fact, many games have started using this model explicitly because it's less expensive than relying on internal QA alone. Much easier to let your (unpaid) community find the bugs for you. It's also the model that most volunteer community coding projects use - tools like GitHub exist for pretty much exactly that purpose.

Doesn't really require any additional admin, either, outside of maybe a special forum section for people to post beta-specific feedback and bug reports. We're not talking about a server-side MMORPG or something, here, where it definitely would be a significant allocation of resources; we're talking a single-player game with limited client-side multiplayer capabilities.
 
Last edited:
  • 2
  • 1Like
  • 1
Reactions:
Huh? Why would a beta release require extensive repurposing of funds? Releasing opt-in preview or test builds that the devs are currently working on for community feedback isn't exactly an arduous extra step, and is something other much smaller devs (and Paradox itself in other games) do all the time without an issue. In fact, many games have started using this model explicitly because it's less expensive than relying on internal QA alone. Much easier to let your (unpaid) community find the bugs for you. It's also the model that most volunteer community coding projects use - tools like GitHub exist for pretty much exactly that purpose.

Doesn't really require any additional admin, either, outside of maybe a special forum section for people to post beta-specific feedback and bug reports. We're not talking about a server-side MMORPG or something, here, where it definitely would be a significant allocation of resources; we're talking a single-player game with limited client-side multiplayer capabilities.
You are assuming the feature branches are merged to a playable build early in the process.

You are asuming the studio has a similar workflow as a GitHub community project.

GitHub is a hosting service. It does not magically give you a set of work practices if you host your projects there.

The workload to turn beta feedback into a product change can include:
- Find the correct users for testing
- Compile and evaluate user feedback
- Make technical solution proposals
- Estimate the solutions
- Change project priorities to implement the changes
- Regression test the product again

Please share the information about PDX internal processes, organization and work practices you used to make your analysis.
 
  • 2
Reactions:
You are assuming the feature branches are merged to a playable build early in the process.

You are asuming the studio has a similar workflow as a GitHub community project.

GitHub is a hosting service. It does not magically give you a set of work practices if you host your projects there.

The workload to turn beta feedback into a product change can include:
- Find the correct users for testing
- Compile and evaluate user feedback
- Make technical solution proposals
- Estimate the solutions
- Change project priorities to implement the changes
- Regression test the product again

Please share the information about PDX internal processes, organization and work practices you used to make your analysis.

As I said, they already do it. And, really, truly, it's an incredibly common and simple thing within the industry. They already have the build they're working on, because that's how software development works. Opening that build (or often one build behind the current dev build so they can be responsive to feedback) to public comment is truly not a major commitment of resources. You appear to be approaching this from a... highly formalized and structured concept of a "beta test," I suppose, and that's not at all universally applicable. There is no "find the correct users for testing" step in an open opt-in beta, for example.

Regarding GitHub, I brought it up as an example of how forked and branched software development works on a scalable level - those ideas are not unique to GitHub. Rather, GitHub is structured that way because that's usually how software development works. They made it with software developers in mind. The structure of GitHub is responsive, not prescriptive.
 
Last edited:
  • 1Haha
  • 1
Reactions:

As I said, they already do it. And, really, truly, it's an incredibly common and simple thing within the industry. They already have the build they're working on, because that's how software development works. Opening that build (or often one build behind the current dev build so they can be responsive to feedback) to public comment is truly not a major commitment of resources. You appear to be approaching this from a... highly formalized and structured concept of a "beta test," I suppose, and that's not at all universally applicable. There is no "find the correct users for testing" step in an open opt-in beta, for example.

Regarding GitHub, I brought it up as an example of how forked and branched software development works on a scalable level - those ideas are not unique to GitHub. Rather, GitHub is structured that way because that's usually how software development works. They made it with software developers in mind. The structure of GitHub is responsive, not prescriptive.
Iirc, Paradox uses Jira for their internal bug tracker and workflow(?)

Open beta's aren't a very simple thing to do. They're a huge time investment because of the sheer volume of user feedback that needs to be filtered through. A project needs to have the required time to do an open beta and still be able to reach their release deadline in an acceptable timeframe.

But you know, dead game and all that so why even bother? :p /sarcasm
 
Iirc, Paradox uses Jira for their internal bug tracker and workflow(?)

Open beta's aren't a very simple thing to do. They're a huge time investment because of the sheer volume of user feedback that needs to be filtered through. A project needs to have the required time to do an open beta and still be able to reach their release deadline in an acceptable timeframe.

But you know, dead game and all that so why even bother? :p /sarcasm
What is your opinion of the open thread for feedback? I thought there were formal formulaires to classify the data to analyze it. Is it going to be useful beyond the anecdote?

 
Open beta's aren't a very simple thing to do. They're a huge time investment because of the sheer volume of user feedback that needs to be filtered through.
There certainly is some additional administrative load, especially if there's no existing feedback system in place. However, given that there are already Paradox teams in place that track feedback on the forum (presumably where the open beta feedback would also live), I don't imagine it would result in that much of an extra load, since A.) the number of people who opt in to the beta would be comparably low to the number of people who don't and still contribute on the forums and elsewhere, and it would primarily be forumites that knew about the ability to opt in in the first place, and B.) since there's already tons of feedback to go through anyway, open beta feedback would at least be more targeted and specific, which honestly might be easier to parse.
 
What is your opinion of the open thread for feedback? I thought there were formal formulaires to classify the data to analyze it. Is it going to be useful beyond the anecdote?

I think that any additional community-developer interraction is a net positive. Despite the unconstructive feedback that occasionally mixes in with the constructive ones, there's always a lot of insight to be gained from players who do play your games for hunderds of hours, who are able to relay suggestions constructively.

Of course I'm in favor of open beta's, I'm just not convinced they are 'easy' to do. If they were, we'd see a lot more of them. Then again, only one of the developers can really shed some light on this, perhaps they already have.
 
  • 1Like
Reactions: