Author Topic: The TODO List  (Read 441 times)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1683
  • Karma: +72/-6
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
The TODO List
« on: September 07, 2016, 11:07:06 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. It is safe to assume that the things on this list have been looked over by Tom, though it may contain things that have been specifically rejected (so we don't get more suggestions for them).

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.
Cycles:
  • Create a Conversation Cycle handler to handle conversation updates. Work in progress.
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.
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).
  • Change gear production so that you produce individual items rather than "hours".
  • TODO: auto-abandon buildings in a crisis (but not food-bonus buildings!)
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. Should be an easy kill, assuming I did the whole realm-revival thing right. 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.
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.
  • 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.
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. Needs testing.
  • 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. :)
Permissions:
  • Add title-holders to lists. This shouldn't be hard, as positions are entities just like characters and realms are.
  • Finish permissions, see next 2.
  • Finish mobilize troops permission.
  • Finish manage trade permission
Publications:
  • Fix subscriptions. Rather, make them actually work.
  • Fix weird stacking thing.
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. I was playing with making this functional, it won't be 'easy'. Something about how votes are actually conducted just doesn't want to work right when it comes to including the other types of elections.
  • 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 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.
Concepts:
  • Diplomacy Chart for players. Tie into Palaces update.
  • World stats for players (Total realms, population, etc., nothing too revealing).
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.
  • 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 probably 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 don't use markup syntax. Why not?
« Last Edit: June 16, 2017, 04:32:38 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)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1683
  • Karma: +72/-6
  • 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: 1683
  • Karma: +72/-6
  • 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)

Andrew

  • Game Master / Lead Developer
  • Administrator
  • Sr. Member
  • *****
  • Posts: 1683
  • Karma: +72/-6
  • Mildly Amused
    • View Profile
    • Lemuria Community Fan Site
Re: The TODO List
« Reply #3 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)