Author Topic: The TODO & Concept List  (Read 1277 times)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
The TODO & Concept List
« on: September 07, 2016, 11:03:49 AM »
This is a slightly stripped down version of a larger list I maintain (there are somethings I think it'd be cooler to surprise people with), that may give any interested devs something to work towards. All in all, this is a list of things we'd eventually like to add to the game.

Characters:
  • Adoptions/Wards
  • Duels
  • Fix heraldry not transferring to spouses/non-user children. Make heralrdy inter-player depending on relationships as originally intended.
    --> See reply #1
    Completed.
  • Custom welcome messages, maybe attach publication links?
  • Kill bandits, take their gold. (Maybe add a small amount to bandits that don't have gold on them, for incentivizing it?)
  • BUG: Make sure Bandits are no longer set to inside a town upon death/regen
  • TODO: Extend the bandit framework to actually include functionality for grabbing slumbered bandits from players at times other than when we need more bandits.
  • Action to disembark from ships when near shore. Game seems to have some issues when players stop travel very near but not quite on the shoreline.
  • BUG: Characters that kill themselves should no longer be a prisoner.
  • ABUSE: Remove ability to set new heir while imprisoned.
  • Incentivize having knights and keeping them.
  • Change your equipment (you know, deviate from the sword/warhorse/plate if you want, for some reason)
  • Semi-alternative to the above, make dungeons have their own equipment set. I mean, going in in plate in confined spaces may not be the wisest idea.
  • Default inheritance laws for when an heir isn't set. (Spouses get stuff if they are alive, children get it after them, dynasty head gets it after that?)
  • Give characters an inventory, so that they may hold items.
  • Modify existing slumber flag to be a date, add second flag for a week later, and base character conversation targets on this second flag.
Cycles:
  • Create a Conversation Cycle handler to handle conversation updates.
Dungeons:
  • Fix the errors thrown when in dungeons. I think these are caused by an error in the .yml somewhere. Possibly because the .yml includes the new options/monsters/cards that don't exist in the database yet. That or I don't know how to type. Very possible. Fixed.
  • Convert dungeons to use the same database type existence as cards and monsters and such
  • Make dungeons play out dependent on the type of dungeon Convert dungeons to the same setup as cards/monsters first so we have to rework less later.
  • Add more card "decks".
  • Add more cards.
  • Add more montsers.
  • Add more dungeons.
  • Add stuffs.
  • Get translations.
  • Allow these to be tied into complexes? For RP-value and such? Hm.
  • Dungeoneer tournaments (outside dungeon PvP, basically).
  • Add classes and class specific cards?
Economics:
  • Figure out how to add stone. This is really easy actually. It's a new entry on ResourceTypes table and then a freaking ton of entries on the region resources table (I forget the table name atm). Maybe we should just build a command that populates this for all the regions, then go in and update values where needed.
  • Change gear production so that you produce individual items rather than "hours".
  • TODO: auto-abandon buildings in a crisis (but not food-bonus buildings!)
  • Add in specific industries, such as the production of leather and paper for the making of books, and the reproduction of books at temples, for instance.
  • Overhaul Trade / Add trade caravans/fleets/hubs/etc.
  • Gold sinks. Many.
  • Allow others to use ports/inns/resupply/etc for a fee?
Equipment:
  • Change equipment from current 3-slot system to more common 9-slot system (Head, Chest, Arms, Legs, Boots, Hand x2, Back, Equipment/Special).
  • Make equipment more or less effective based on who it's attacking and what it hits.
Estates:
  • Levy taxes. Most, if not all the code, already exists to do this in one place or another.
  • Grant estates at a distance.
  • Create estate offers at a distance.
  • Abandon estates at a distance.
  • Add current militia numbers to recruit troops page.
  • Add current economic numbers to building pages.
  • Realm capital structures. See Palaces - Phase 1 below.
  • Make roads destroyable.
  • Make region features destroyable.
  • Buildable Fortifications on the Map.
  • Buildable Points of Interest: manors, statues, memorials, plazas, etc.
  • Dynamic regions (alternatively titled: "Shattered Regions" or "Mini-regions")
  • Settling unclaimed land (no more pre-made settlements on previously unvisited lands)
Events:
  • Fix oath break event to be gender specific.
  • Make appointment of rulers the same level of event as abdication of a ruler.
Map:
  • Diplomacy map-mode - Phase 1: Start with showing things relative to YOUR realm. After that we can implement it for other realms.
Messages:
  • Mark all conversations read for this character
  • Mark conversation as read across all characters
  • Fix message tags not being functional when loaded from a nested conversation message
  • Have conversation show which realm they are in
  • Add a ruler conversation Canceled per Tom.
    Adapt the work done on this into a framework for associations?
  • Update the message system so that instead of a realm tag it has a groups field and a special field. A separate table in M&F can be used to connect realm/association/whatever IDs to messaging bundle group IDs. Special field would be used for things like a new player conversation or a GM conversation or whatever. Special field, now titled "system" has been implemented.
  • Change app_user in messagingbundle to work same way that the message groups are described above. This can be done by breaking the direct association from the msg bundle app_user to characters and changing it to a secondary table that sorts out what type and what id (maybe by using multiple columns for each ID type or by having 1 column for type and a second column for whatever ID--the latter won't allow entity mapping natively though), or by adding another column that allows it to be associated to a M&F User id. The last one would require reworking the messaging bundle a bit I think though. We may have to convert the existing app_user field to a new field if we want to properly implement this without breaking every realm conversation.
Military:
  • 3+ sided battles. Ideally, this will expand into allowing you to choose your primary and secondary targets and such. The tricky part is displaying it in a way that makes sense.
  • Loot Option: Kill population
  • No experience if fighting a slumbered first one. Implemented.
  • Add functionality to manage prisoner forces. Probably restrict to steal equipment, release, and execute though. Make it so captured mercenaries can't leave until released.
  • Extend mercenaries so they have a company of origin, then make it so if you execute them you can't hire from them later. :)
  • Add naval escorts to go along with the trade fleets for the trade overhaul.
  • Add piracy, because trade.
  • Sieges
  • Siege weaponry
  • Overhaul the orders issuance process - Maybe make it so the game tells you what you have count wise, and you simply tell it to do X with Y soldiers that have A, B, C equipment, then tell it to favor either experienced or unexperienced (or to not at all). I don't think that'd be hard to express in a PHP equation with some good usage of arrays.
Permissions:
  • Add title-holders to lists. The permissions system is setup for this from one of my updates, just need to add the input to the form to parse it.
  • Finish permissions, see next 2.
  • Finish mobilize troops permission.
  • Finish manage trade permission
  • Make more player-friendly. Rather than redesign the entire system, add an overlay that lets you do the basic things automatically? Things like: allow $realm to do $thing, allow $character to do $thing, don't allow $realm to do $thing, then have the game automatically setup those and explain it all to the player in an easy to understand way. Ideally, we'll keep the ACL format for "advanced view".
  • Add permission option for local buildings (this would control access to inn, tavern, town hall, etc.)
  • Perhaps even make it so it's specific to particular buildings, if people want.
Places:
  • Certain places, specifically those that are community ones rather than private ones, should have a short term discussion system built into them.
Publications:
  • Fix subscriptions. Rather, make them actually work.
  • Fix weird stacking thing.
  • Add books.
  • Tie them to the libraries as well as the characters.
  • Printing presses? A way to make copies and distribute them?
  • Charge wealth for newspapers? / Sell newspapers?
Quests:
  • Make quests cancellable.
  • Make quests be permanent (meaning multiple people can complete it, good for setting up new player intros/tasks).
Realms:
  • Make realm pages viewable when logged in rather than only when playing a character. Completed.
  • Finish elections. I swear, everytime I look at this, it looks like it's 95% done already. Completed.
  • Add polls/multiple choice voting.
  • Flags. Paid feature? Still. Flags. 'Nuff said.
  • Finish realm laws. Make them do stuff.
  • Revive subrealms. Completed.
  • Revive sovereign realms. If the above works, the majority of the code for this is already done.
  • Palaces - Phase 1. Or rather, seats of power. Presently, I'm thinking there will be 3 seats of power: local, regional, and imperial; that will initially do a few things. 1) they'll allow you to see the world diplomacy. 2) they'll be an experiment in customizable buildings. that is, they'll let you express your realm a bit. 3) lastly, their location will show up on the realm info pages (making them targets :D ). Tie these into a Places of Interest system? Ideally, since PoIs will use custom names and such, this would be ideal. Work in Progress.
  • Eject dead/inactive sub-realms.
  • Automatically eject dead sub-realms when demoting sovereign realm.
  • ^ Maybe do this for all realms, perhaps with a secondary confirmation for living realms?
  • BUG: Can't change realm superior to a realm you yourself are part of.
  • Realm law for inheriting of estates on death and/or slumber
  • Realm law for inheriting of positions on death and/or slumber
Users:
  • Expose User ID on personal profile
  • Add a resend activation email link
  • Possibly add a way for unactivated accounts to login and change registration details.
  • Or, you know, change it all to noCAPTCHA or reCAPTCHA or something.
Concepts:
  • Diplomacy Chart for players. Tie into Palaces update.
  • World stats for players (Total realms, population, etc., nothing too revealing).
  • MUD-like player "complexes" for immersion. Not mandatory, purely optional. We could make these semi-paid, allowing anyone to make the simpler ones, but lock some of the more complex ones behind a small paywall, 5-10 credits per "room" or perhaps once over a certain build limit per settlement (15+? 20+?), or even make it so there are types and certain types are "premium"? Ideas. By default, all of these will involve settable permissions, as well as the ability to tie rooms to certain buildable structures, allowing you to enter the inn, and see how a player describes their inn. Allow tying in knight offers to this so they can start in a "room", for immersion and stuff. Allow one-way rooms?
  • Player Associations. These would probably range from strictly a guildhouse type thing to meta-realm concepts. Allow local branches to exist in each realm with a guild headquarters that may or may not be part of a realm? Needs to be able to hold land to accomodate trade guilds and mercenaries, needs to be permission based to permit secret societies, needs to not necessarily be visible to local lords (because societes are more fun that way). Tie into complexes because why not (especially for secret societies). Allow associations to "own" other associations. Mercs get discounts on mercs? Traders get discounts on caravans/fleets? Ideas....
  • Religions. These may or may not actually contribute to the game much, but I'd prefer the option exists. May be able to straight out tie these into the Associations above, as a type of association.
  • Tournaments. Tournament structure itself, how it's determined, where it is, etc. Part of Places of Interest maybe?
  • Dynamic darkness.
  • Leagues, collections of sovereign realms that tend to act cohesively. Like the HRE or italian city states or hanseatic league or something.
Other:
  • Fix the FIXMEs.
  • Do the TODOs.
  • Explain every little thing the code does, when the code does it, in the code. Comments, you know?
  • Link to wiki in game. Completed.
  • Expand wikilink system to include wiki. The messaing system hates this. We'll need to do a separate unique converter that takes precedence over the existing message system converters.
  • Standardize use of in-game markup language. There are a couple places it's not used for reasons unknown.
  • Shameless copy BM forum announcement thing-a-ma-bob. Doing this the exact same way will only work if the game and the forum are on the same server, which will never happen. Explore alternative solutions or scratch it?
  • Translations. Bring back a translation tool. Tie it into the game's user database rather than github's, though.
  • If you have permissions for settlement management, it should appear in the menu like if you were a lord.
  • Position descriptions and Realm Relations don't use markup syntax. Why not?
« Last Edit: November 23, 2017, 10:47:08 AM by Andrew »
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The TODO List
« Reply #1 on: September 08, 2016, 04:11:14 PM »
I don't have the time to do the work on this myself, but making heraldry work for all family ties rather than just your own should be fairly easy.

The code that handles getting the crests right now is located here: https://github.com/tvogt/mightandfealty/blob/master/src/BM2/SiteBundle/Controller/CharacterController.php#L887

That needs to be adapted to also search for any crests used by family members (to include spouses). The simplest way to do this would be to create a method in the character controller called something like getAllParents that does something like "$charparents = $this->getParents" and "foreach($charparents as $cp) {$allparents[] = $cp->$this->getParents}". That part should be done on the character entity page as a method, so if we need to use it later for some other thing, we don't duplicate work.

Back to the CharacterController.php, you'd modify the method at line 887 to have something like "foreach($allparents->$this->getCrest as $ap) {$famcrests[] = $ap->getID}" and after that we can do this "$availcrests = array_merge($famcrests, $available)" and then change "function(EntityRepository $er) use ($available)" to "function(EntityRepository $er) use ($availcrests)".

Given that I should be asleep, this is just a rough draft of where'd I'd start working on this at. It should be noted I didn't include anything for grabbing the spouse(s)'s crest(s). That will involve "getPartnerships", a foreach method (because you can have multiple) with an internal if method to check whether they're the right type of partnership to share heraldry (married), and from there you can get the character IDs and do the whole get crest thing I explained above to get the crest IDs to load as options.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The TODO List
« Reply #2 on: September 11, 2016, 12:17:57 PM »
Added the following.

Estates
  • Make roads destroyable.
  • Make region features destroyable.
Quests:
  •     Make quests cancellable.
  •     Make quests be permanent (meaning multiple people can complete it, good for setting up new player intros/tasks)
« Last Edit: September 11, 2016, 03:49:36 PM by Andrew »
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Ehndras

  • Full Member
  • ***
  • Posts: 279
  • Karma: +9/-8
  • Urist Tarzath, Emperor of the Children of Armok
    • View Profile
Re: The Concept List
« Reply #3 on: November 29, 2016, 04:51:11 PM »
All of the above. *throws pretend money at you*
Mors Principium Est - Death is only the beginning

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The Concept List
« Reply #4 on: November 29, 2016, 05:24:29 PM »
All of the above. *throws pretend money at you*

If you want them, start helping De-Legro, Weaver, and I figure out how they'd work.

Or suggest things you'd think would make good additions as well.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Cipheron

  • Full Member
  • ***
  • Posts: 186
  • Karma: +7/-4
    • View Profile
Re: The Concept List
« Reply #5 on: December 18, 2016, 07:54:33 AM »
Quote
Incentivize having knights and keeping them.

Right now I have one duchy which has a lot of lands controlled by a single character. I can then click Status -> Estates on that one character and get an overview of the entire realm's military and training. If I was to split those towns between multiple characters (even my own) then I lose the ability to get the overview, which would make my militarization a lot less efficient. It's these sorts of strategic/tactical advantages that need to be nullified if it is going to make sense to want to hand settlements out for any reason other than reducing corruption.

Some suggestions to move things in the right direction:

- per-character corruption: maybe it kicks in after 3 settlements, and adds 0.1% per settlement after that, on top of the per-account corruption. This would remove some of the advantage of having a single character with massive personal holdings.

- better overview of settlements for people with vassals. Having one character with all the settlements is a huge advantage in terms of optimizing training, due to the Status->Estates screen, but it's bad for immersion and roleplaying. Perhaps, characters should get info about their vassal's holdings on this page as well, and if they're a ruler, also any settlement that's a direct member of the realm. But not subrealms, so as to maintain intrigue and communication / roleplaying. This would level the playing field in wartime between big solo players and realms made of many players.

~~~

As for incentivizing knights, how about a "prestige" rating for each character? The idea is that it would give a morale / productivity boost, but split between all your towns. A knight with no subordinates would have Prestige 1. A lord gets Prestige 1 + 50% of the prestige of all direct vassals. Anyone who's not a vassal, but is part of a realm gives 50% of their prestige to the higher realm ruler(s). This would include people who are leaders of subrealms: they provide prestige for the rulers of realms to which they are subordinate.

Obviously, we should run the numbers on this and work out how the bonuses would work to make sure it's not really exploitable (i.e. make sure it doesn't circumvent the corruption system that currently exists). But right now I have some assignments to work on so that's all I can write for now.
« Last Edit: December 18, 2016, 08:58:38 AM by Cipheron »

De-Legro

  • M&F Dev Team
  • Sr. Member
  • *****
  • Posts: 3109
  • Karma: +105/-54
    • View Profile
Re: The Concept List
« Reply #6 on: December 18, 2016, 11:11:57 PM »
Right now I have one duchy which has a lot of lands controlled by a single character. I can then click Status -> Estates on that one character and get an overview of the entire realm's military and training. If I was to split those towns between multiple characters (even my own) then I lose the ability to get the overview, which would make my militarization a lot less efficient. It's these sorts of strategic/tactical advantages that need to be nullified if it is going to make sense to want to hand settlements out for any reason other than reducing corruption.

Some suggestions to move things in the right direction:

- per-character corruption: maybe it kicks in after 3 settlements, and adds 0.1% per settlement after that, on top of the per-account corruption. This would remove some of the advantage of having a single character with massive personal holdings.

- better overview of settlements for people with vassals. Having one character with all the settlements is a huge advantage in terms of optimizing training, due to the Status->Estates screen, but it's bad for immersion and roleplaying. Perhaps, characters should get info about their vassal's holdings on this page as well, and if they're a ruler, also any settlement that's a direct member of the realm. But not subrealms, so as to maintain intrigue and communication / roleplaying. This would level the playing field in wartime between big solo players and realms made of many players.

~~~

As for incentivizing knights, how about a "prestige" rating for each character? The idea is that it would give a morale / productivity boost, but split between all your towns. A knight with no subordinates would have Prestige 1. A lord gets Prestige 1 + 50% of the prestige of all direct vassals. Anyone who's not a vassal, but is part of a realm gives 50% of their prestige to the higher realm ruler(s). This would include people who are leaders of subrealms: they provide prestige for the rulers of realms to which they are subordinate.

Obviously, we should run the numbers on this and work out how the bonuses would work to make sure it's not really exploitable (i.e. make sure it doesn't circumvent the corruption system that currently exists). But right now I have some assignments to work on so that's all I can write for now.


The corruption system is certainly something I want to review. Keep in mind it exist as it does now not to stop individual characters from owning lots of land, but to stop individual accounts with 50 characters from owning lots of land. The reality is that Tom's stance on multiple paid accounts somewhat lessens the result.


What I proposed was a two tier system. Character level corruption that kicks in after x amount of settlements are owned by the character, with a exponential increase per estate over that limit. Similarly a account wide corruption that kicks in over y amount of settlements, also with a exponential increase (most likely a smaller one) that affects all estates on the account.


With regards to settlements, several of us have argued that we need better "overview" of vassals for a long time, but I can't see it being on the level of knowing exactly what buildings they are building or what they are training. That only encourages micromanagement of your vassals, or allows players with lots of characters to split up estates to minimise character level corruption, while still allowing them to log into a single character to see what is going on. Remember tedium and such is part of the design to stop people from running too many estates themselves.


Anything that boost settlements for the amount of vassals held has been rejected before. The methods to abuse that should be obvious. If the boosts are so small that people won't bother to abuse them, then they also don't actually offer incentives.
He who was once known as Blackfyre

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The TODO List
« Reply #7 on: June 08, 2017, 06:03:45 PM »
Updated the list above a bit. Also, I wanted to talk about this one here, now that I've finished it . . .

I don't have the time to do the work on this myself, but making heraldry work for all family ties rather than just your own should be fairly easy.

The code that handles getting the crests right now is located here: https://github.com/tvogt/mightandfealty/blob/master/src/BM2/SiteBundle/Controller/CharacterController.php#L887

That needs to be adapted to also search for any crests used by family members (to include spouses). The simplest way to do this would be to create a method in the character controller called something like getAllParents that does something like "$charparents = $this->getParents" and "foreach($charparents as $cp) {$allparents[] = $cp->$this->getParents}". That part should be done on the character entity page as a method, so if we need to use it later for some other thing, we don't duplicate work.

Back to the CharacterController.php, you'd modify the method at line 887 to have something like "foreach($allparents->$this->getCrest as $ap) {$famcrests[] = $ap->getID}" and after that we can do this "$availcrests = array_merge($famcrests, $available)" and then change "function(EntityRepository $er) use ($available)" to "function(EntityRepository $er) use ($availcrests)".

Given that I should be asleep, this is just a rough draft of where'd I'd start working on this at. It should be noted I didn't include anything for grabbing the spouse(s)'s crest(s). That will involve "getPartnerships", a foreach method (because you can have multiple) with an internal if method to check whether they're the right type of partnership to share heraldry (married), and from there you can get the character IDs and do the whole get crest thing I explained above to get the crest IDs to load as options.

Some things in the code aren't hard. While that described above isn't how I implemented this, it was, comparatively, one of the easier things I've done involving only 3 files, and 13 actual lines of code. To do it, I looked at the existing code for generating the heraldry list:

Code: [Select]
      foreach ($character->getUser()->getCrests() as $crest) {
            $available[] = $crest->getId();
         }

What this does is take the current character, get the associated user, then get that user's heraldry, "$character->getUser()->getCrests()", and handles them individually, "as $crest". From there, it adds them by Heraldry ID, "$crest->getId()", to an array called "$available". That's the 2 brackets after $available, which mean anything after the = are to be added to the existing array. And an array is a collection of other variables that are handled as a single variable unless otherwise indicated.

The next chunk of code simply adds the parent's crests:

Code: [Select]
      foreach ($character->getParents() as $parent) {
            $parentcrest = $parent->getCrest()->getId();
            if (!in_array($parentcrest, $available)) {
               $available[] = $parentcrest;
            }
         }

This time, instead of getting the user, it gets the parents of the current character, and for each of them looks at which heraldry they are currently using and fetches the ID of that heraldry (if any). After that, "if (!in_array($parentcrest, $available))" tells the game that it should see if the heraldry of the parent is already in the $available array. If it's not, it adds it, "$available[] = $parentcrest;".

The last chunk of code, is a little more complex, because we start handling character relations as well:

Code: [Select]
      foreach ($character->getPartnerships() as $partnership) {
            if ($partnership->getPartnerMayUseCrest()==TRUE) {
               foreach ($partnership->getPartners() as $partners) {
                  $partnercrest = $partners->getCrest()->getId();
                  if (!in_array($partnercrest, $available)) {
                     $available[] = $partnercrest;
                  }
               }
            }
         }

As you can see, we're still working from the current character--most things in M&F do actually--but instead getting that characters partnerships. Regardless of type or level, be it a marraige or liaison, the game calls it a "Partnership". Since this can return more than one, we do a foreach call on them, and handle them each individually as $partnership, and look for any that have "PartnerMayUseCrest", an attribute of any partnership, set to TRUE. For those, we get the heraldry ID of the partners in a relationship (this actually includes both characters, for what it's worth) and then add it to the available list, if it's not already there.

If you've an interest in learning PHP or coding, and think this is all very intimidating, I really don't mind helping people out. I started at zero last year, and now I can crank out things like this in under an hour and can even pull fast ones on Demivar in chat by doing a super-quick update in a few minutes. More people interested in helping keeps me interested in developing, and helping someone else learns gives that warm fuzzy feeling.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

New Player 123

  • Jr. Member
  • **
  • Posts: 24
  • Karma: +0/-0
    • View Profile
Re: The TODO & Concept List
« Reply #8 on: October 03, 2017, 04:40:12 PM »
I should've suggested this before you went live, but it just now occurred to me due to some intra-realm politics that just popped up.

Can you get the system to count all knights in a realm when tallying votes. By all, I mean even knights who don't vote. This would allow things like absolute majorities (or maybe even super-majorities) instead of the simple-majority-only votes we have now. Ideally, it would only count active characters (not slumbers), but if it can distinguish between the two, providing both as options (absolute majority vote including slumbers vs absolute majority vote excluding slumbers) would be cool since it's impossible to predict where a realm's politics might lead it in terms of voting systems.

Other cool vote types would be: vote by subrealm (so only rulers can vote), vote by realm level (so only rulers of certain ranks can vote), and vote by house ("house" as in account, so a player can only vote with one of their characters instead of skewing votes with puppets).
« Last Edit: October 03, 2017, 06:23:06 PM by New Player 123 »

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1797
  • Karma: +75/-7
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The TODO & Concept List
« Reply #9 on: October 04, 2017, 10:46:16 AM »
Tallying votes, depending on the type of vote, would reveal a lot of info about a realm in a way that I'd prefer I not do. And to make a response to a discord conversation about it, if you want to know how many troops you have active in your realm, accept that it'll be public or just ask.

That said, depending on the type of vote, it'd make sense, though I'm not sure how easy it'd be to implement for the more complex ones. If you have a Bug Tracker account on the new one, feel free to throw it up as a feature request.

Vote by subrealm, approved (again, feature request please).

Vote by realm level, I'll have to think about. Not because it's a bad idea. I rather like it, but because we need to implement it right, and the logic for it would be.... interesting. I mean I could do a quick and dirty one now--it's not far off from hwo the fortification logic works. Anyways, I guess approved pending further research.

Vote by house, I'm going to decline this one. I'm against anything that makes it more possible to figure out who plays what characters. One of my very first additions was something that obfuscated that very info, and that was sharing heraldry across accounts. In fact, I'd love to make it more difficult. Someone should marry my characters so I have an impetus to make an option for disabling the vip banners.

That said, I am implementing dynasties soon, which will have similar voting block logic, possibly. Or at least, I'd like them to.
Standing for the creation of interesting things since Year 1, Week 5, Day 4.
Favorite cold beverage: Strawberry Shake
My hobbies: Fixing computers, video games, anime, manga, some other stuff, sleep (in no particular order)

Cipheron

  • Full Member
  • ***
  • Posts: 186
  • Karma: +7/-4
    • View Profile
Re: The TODO & Concept List
« Reply #10 on: October 05, 2017, 06:18:09 AM »
You know what I'd like to see - is the ability to create children then have them become offers such as a knight's offer. So you could have a character, marry another player's character, then your child is a third player's character. That would add additional obfuscation to the game plus allow some more roleplaying opportunities.

NOTE: this idea, like knight's offers in general might be exploitable/trollable, so perhaps there could be an "honor" system. e.g. if the liege could rate their recruited knights / children based on how honorable they are, and you couldn't take another knight's offer straight away if your honor fell too low. This system would be both anonymous and provide feedback to the game as to which accounts are playing the knight's roles "honorably".

A basic outline would be that each account starts with 20 honor points, and it costs 5 honor to take a knight's offer.  So if you e.g. take 4 offers then suicide, you can't keep spamming that with the same account, but it's enough for a starting player. Then, some mechanisms would be in place to award or recoup honor based on what happens to your knight character. e.g. suiciding a new knight should lose the honor, but being killed in a defensive battle should recoup the honor. Breaking your oath would also lose the invested honor. Some systems here could also keep lords accountable for treating their vassals right.

So there would be some high-level automated stuff in there that rates knight players on reliablity, and it could have an added thing in which lords can manually grant honor to their subjects, giving some subjective feedback and in-game rewards as well. Then, as the final piece, knight's offer creators could specify how much honor they want for each offered position instead of a default value, so you could differentiate between open roles (avaliable to all new players) vs roles that require you to have shown that you are a reliable knight at an account level.
« Last Edit: October 05, 2017, 06:42:37 AM by Cipheron »

New Player 123

  • Jr. Member
  • **
  • Posts: 24
  • Karma: +0/-0
    • View Profile
Re: The TODO & Concept List
« Reply #11 on: October 05, 2017, 11:37:02 AM »
If you have a Bug Tracker account on the new one, feel free to throw it up as a feature request.

The new what? It doesn't sound familiar, so I'm guessing I don't have a Bug Tracker account.

Vote by subrealm, approved (again, feature request please).

Vote by house, I'm going to decline this one. I'm against anything that makes it more possible to figure out who plays what characters.

Yeah that makes sense. I suggested it as a way to have one vote for publicly-acknowledged relatives, not for characters who intentionally have no familial relations. I shouldn't have said "by Account."

That said, I am implementing dynasties soon, which will have similar voting block logic, possibly. Or at least, I'd like them to.

Yeah, something like that might be necessary for this one. Because currently, even if two characters share the same parents, their player doesn't necessarily intend for them to be considered part of the same House (or "dynasty"), so even using player-created family relationships as the "same House" flag (to preserve player anonymity) wouldn't be enough for voting purposes.