Recent Posts

Pages: [1] 2 3 ... 10
1
General Discussion / Re: What is an Artifact worth? (In Credits)
« Last post by Dystopian on Today at 10:15:12 PM »
Oh god, I don't wanna say how much I'd cough up for it! I'm sure a lot of people have wasted their artifact. Mine is tied to the founder of my House and so it'll always have a small sentimental place for me at least, and a reason for war at best. What's yours Andrew? The people need to know.
2
General Discussion / What is an Artifact worth? (In Credits)
« Last post by Andrew on Today at 04:12:40 PM »
Poll kind of says it all.
3
Realms Chat / Re: The Kingdom of Ascalon
« Last post by Dystopian on Today at 05:39:45 AM »
I have to admit this game does still make me feel that I'm at least part of the history of the game. Just like BM.
4
Conduct & Design Discussion / Re: New Permission System Design
« Last post by Andrew on October 13, 2017, 01:30:49 PM »
I'd not even make that setting use the existing lists system. It'd be far simpler to jsut have the game do something like "if (in_array($settlement->getLord()->getUser()->getCharacters(), $currentcharacter) { allow } else { deny }". If I'm understanding the code right, I think that logic would be part of this function: https://github.com/Zanaras/MaFCDR/blob/master/src/BM2/SiteBundle/Service/PermissionManager.php#L52, along with an update to the form used to select settlement permissions to allow that as an option. We would possibly also want to make that a user profile selectable, so there could be a default setting for players to have when taking over a settlement.

Someone mentioned somewhere to allow RealmPositions to be on lists, technically, they already can be. It's just not fully implemented. I THINK all that we'd need to do is expose the field on the form, build a search method for it (by stealing the one used for realms, settlements, or characters and modifying accordingly), then edit this line here: https://github.com/Zanaras/MaFCDR/blob/master/src/BM2/SiteBundle/Service/PermissionManager.php#L121, to include a check for $member->getTargetRealmPosition and whatever logic is needed--it shouldn't differ too much from the character one, just with an additional step to fetch the position holders and see if the character we're looking at is one of them. The database itself already supports this logic, and has since the server move--that is, the field in the database for positions exists on permission list members and has a relation setup to the ream positions. I do sometimes do small updates knowing what I want to do to an area later.
5
General Discussion / Re: Discussion - Subscription Levels
« Last post by Andrew on October 13, 2017, 01:15:09 PM »
If realms cost upkeep, it won't be while I'm running the server.

The EVE Online approach has a few ideas to it though. This is part of why I was debating giving out credits to those who support development of the game, and the game already has free subscription levels for those I think are worth having one (no one does though, not even my own accounts).

If we take the Skyrim approach to skills, it may make it worthwhile to invest in skilling up characters for sale to others, and a highly skilled character could fetch a nice sum, theoretically. Character transfers, at a small fee (to the game, selling characters is debatable), are already on the todo list.

Artifacts are presently on the todo list to be purchasable. I've not determined a price for that though. Could also make them something you get after having so much subscription time. That might encourage people to stay subscribed actually. What would be a good rate, I wonder?

De-Legro mentioned player houses being a subscription or purchasable, but I'm kind of on the fence about that, because they'll already be something that encourages players to have heraldry, and they'll have some in-game mechanics associated to them.

Another idea is making monuments and memorials in cities or on the map a paid item, for like 100 credits or something. I'd want it low enough people would use it, but high enough to make it something done sparingly (because too many damn memorials would be really annoying).

A multi-sub system would be... interesting, though I fear confusing. Right now it's a question of subscribed or not. If there are multiple mini-ones, it's a question of subscribed or not, if yes, which ones.
6
General Discussion / Re: Discussion - Subscription Levels
« Last post by Cipheron on October 13, 2017, 09:07:09 AM »
Well another route is what Wurm Online does. With Wurm Online, group settlements need to pay upkeep, so some players pitch in for that while others tag along.

Translating that to M&F, you'd have something where it costs credits to create or maintain realms/subrealms. The ruler would have a number of means to raise enough credits for the upkeep (e.g. ability to trade credits). With unpaid upkeep however, I'd leave the realm intact but restrict the ability to conduct several areas of business.

Obviously this idea isn't very fleshed out, I'm just putting it out there as a concept for now.

Other than that, you could go for a hybrid system, where players are free to get a subscription to support the game, but that subscription also gives them in-game credits that they can trade to the other players, who might be playing for free. Then you have a bunch of things in the game that need a regular supply of credits but aren't over-powering, such as the realm upkeep I mentioned.
7
Conduct & Design Discussion / Re: New Permission System Design
« Last post by Cipheron on October 13, 2017, 08:35:03 AM »
Well since you control the characters, you're free to ignore that to your heart's content. No-one would make you go and use those towns. If denying access is RP-only then you'd have to explain why you need the rules to default to supporting things the way you want, for every player.

Because you want to RP your own characters not having access to a certain town is no good reason to make it the default that nobody's characters have default access to any of their other towns. you can RP not having access all you want even if access exists. However people can't RP having access when no access exists. It only becomes an issue when people try to access towns that their other characters own. Then they have to go through additional steps of logging out of one character, logging into the other character, editing permissions, then logging back into the original character. So in other words, the only time it impacts gameplay is as a random timewasting hassle when they're trying to do something. If they didn't want the character having that access, then they wouldn't try and access it.

Andrew outlined the solution anyway, if you want to restrict your character's access artificially. That is, to have a new checkbox on the permissions screen saying "allow same player's character access". Then when you click it, it uses the existing list system behind the scenes (to keep the code changes to a minimum). I'd recommend that it defaults to "on" however. Then you'd be free to click it "off" if that supports your roleplaying scenario how you like. But of course the checkbox would be a little redundant here since you can just pretend.
8
Conduct & Design Discussion / Re: New Permission System Design
« Last post by De-Legro on October 13, 2017, 07:54:03 AM »
Well that's why I was thinking a hidden list would simplify things.

- Make the list automatically for new accounts. This should only happen in one place in the code.
- When you create a new character, add them to the list
- when a character dies, delete them from the list
- when you gain control of a settlement, add in permissions for the list

basically this only needs to add code in where things change, not all places that might check permissions. It piggy-backs on already-existing and known working code. it's always better to layer a new system on existing systems than to write special exceptions. Much easier to debug.

But you ignore the question I keep raising. Do you WANT all your character having a single permission list automatically applied to them? Do you want all your settlements to be bound to this list? For example most of my own personal characters have no access to Hawks Hold, indeed very few characters do since there is some RP revolving around it religious significance to Hawks.
9
General Discussion / Re: Discussion - Subscription Levels
« Last post by De-Legro on October 13, 2017, 07:49:53 AM »
I wasn't really talking micro transactions, though they have their place. I was more thinking provide some "cosmetic" features that warrant subscriptions, so I guess something that is compelling and has a reason to pay to keep active. The sub fee for each feature might well be lower then the current subs but you might have more then one sub running to access various things.

It is all pie in the sky though, since as I said to those on Discord, I have no concrete idea's on what to offer in this space right now.

Another option would be to retain the current subscription system, but simplify things to having a single paid account tier.
10
Conduct & Design Discussion / Re: New Permission System Design
« Last post by Cipheron on October 13, 2017, 06:48:24 AM »
I'm on the fence about a hidden "my characters" list, because I can imagine people using it, and people not using it, in different situations. I don't think it'd be hard to code, though, without creating a hidden list--just add a check in the dispatcher somewhere to check to see if this character belongs to the same user. The only downside is that you'd have to add it to EVERY place permissions are checked.

Well that's why I was thinking a hidden list would simplify things.

- Make the list automatically for new accounts. This should only happen in one place in the code.
- When you create a new character, add them to the list
- when a character dies, delete them from the list
- when you gain control of a settlement, add in permissions for the list

basically this only needs to add code in where things change, not all places that might check permissions. It piggy-backs on already-existing and known working code. it's always better to layer a new system on existing systems than to write special exceptions. Much easier to debug.
Pages: [1] 2 3 ... 10