Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Andrew

Pages: [1] 2 3 ... 15
General Discussion / Conversations 2.0: What is the ideal setup?
« on: August 12, 2018, 04:44:52 PM »
So, i've been looking at the conversations system the last few days when I've had time, and the more I look at it, the more I come to think that modifying it to track who has access when to a conversation would be more of a pain than it's worth, based on how it's setup. You might expect that it just track which user has access to what conversations and what messages are in them, when it really tracks which user has access to which conversation and message metadatum and which conversations and messages those relate to, repsectively, and which have what relations to what users. Which makes it a but of a tangled mess, and one I'm not sure it's worth me sitting down trying to untangle.
Thus, I'm entertaining creating a new conversation system, and would like to know what you'd like it to include. I'm entertaining this because if I write one from the ground up, it becomes far easier to track who has access to what messages when, along with fixing most of the problems the current one has (like, how to handle people having access to part of a conversation that they've been since kicked out of--which I've already got a good idea on how to handle).
I'm thinking a rewrite will consist of 3 main parts: conversations, messages, and permissions. Conversations and messages will work mostly how they do now, but permissions will double both as a "who manages this convo" and a "who has access to what messages". When someone joins, they get added to a conversation's permissions with a given start and end period. When permissions change, the old one's get ended and a new one added.
If you're wondering why there's no "User" for this new system, that's because it'll tie straight into M&F rather than be a quasi-dependency like we have now.
Thoughts? Input?

General Discussion / The Next Big Step for M&F?
« on: July 25, 2018, 11:13:37 PM »
Hello everyone,

I've been thinking for several days now what I want to work on next, as a "big project", for the game, and I've not really been able to reach a solid conclusion. A lot of that I think stems from not being certain where the game should end up. Is M&F a strategy game with a side of RPG and city-building, a city-sim with a helping of turn-based strategy and roleplay, or a role playing game with city building and military aspects in it's bag of holding?

Now, I do have plans for what I'll do next, namely taking another go at finishing Places, as well as implementing the GameRequest System in more places in the game, but past that, I need your help in understanding what you see Might & Fealty as. Maybe it's one of the three I listed above. Maybe it's something else entirely.

Please let me know, both what you see it as/use it as, as well as how I can make it a better experience for you.

Thank you.

General Discussion / First Challenge of 2018: The World in Words
« on: May 03, 2018, 11:41:09 PM »
Alright everybody, I'm here to challenge you all to use that fancy new description system we have on all those places you've only been able to describe in roleplays before this--that's right, I want you to describe those settlements!

This will be purely determined by which descriptions I like best, but I will reward 500 credits to whomever does the best "Single Estate Description", 300 credits to the runner up, and 200 credits to the third best.

I am also toying with a categories based on realm-wide consistency/cohesiveness. Consider that a hint.

This challenge will end on May 18th @ 23:59 game time.

Announcements / M&F 1.1 Update
« on: April 08, 2018, 07:47:42 AM »
So, after realizing that trying to do a big massive update was a bad idea, I stripped out all the unfinished bits, finished all the easily finishable bits, and packaged it all up for release.

Might & Fealty is now on version, which includes a number of new features for realms, characters, settlements, and more:
  • Characters
    --Characters are no longer restricted to heterosexual relationships. This is a setting that must be enabled, in the characters setting menu though, as this game is loosely based off medieval society.
    --Validation of character suicide form is now performed server side as well as client side. -- Finishing one of Tom's TODOs.
    --Character suicide screen now lets you edit the death message, and redirects you to view the character page of the fallen upon submit. -- Finishing one of Tom's TODOs.
    --It is now possible to retire a character. In other words, you can remove them from play without killing them.
    --Retired characters get to have a retirement background field, explaining why they retired or what they're doing in their retirement.
    --It is also possible to un-retire characters, bringing them back into regular play, after a bit.
    --Prisoners now properly and fully affect travel speeds. They also slow down travel overall, as transporting prisoners is not routine travel.
    --Account character list now sorts unplaced characters first and retired characters just before the dead characters.
  • Conversations
    --Realm conversations will now identify themselves as a realm conversation when read.
    --Character & message summary unread conversation listing will now identify which realm a conversation is part of, if any.
  • Description Manager (Back-end Service)
    --Added the Description Manager for tracking historical descriptions, linking them to who made them, when, and for what thing.
    --So simple and useful, I convinced the BM'ers they should use it too.
  • Realms
    --Realms can now designate a capital.
    --Realm Positions will now sort between active and retired on the position management page, letting you see at a glance which ones are currently in use.
    --Realms can now be abolished. If sovereign, all sub-realms/estates become independent. If not, all subrealms/estates move up a level.
    --Realm descriptions are now handled by the Description Manager.
    --Realms can now be abolished. Handle with care.
  • Settlements
    --New buildings: Apothecary, Arena, Dockyard, Moats, Guild District, Guild Square, Quarry, Race Track, Royal Seat, Warehouse, Regional Seat, Local Seat, Imperial Seat.
    --New permissions: "Create Place Inside" and "Create Place Outside"
    --Settlements now display their realm when select on the map, and their top-level realm if that is different.
    --The game will now inform you of existing militia and recruits when trying to train more.
    --Settlements now have user-editable descriptions, handled by the Description Manager.
  • User Experience
    --New players are no longer able to place new characters directly on the map. Knight offers are now more important.
    --Invalid credentials on login attempt will no longer dump database info.
    --(Shorter) Announcements will now display on login page/box.
If you find any bugs, please let us know!

General Discussion / A Discussion On The Value Of Characters
« on: April 05, 2018, 01:21:19 PM »
So, Might & Fealty, is a game about characters and what they do, but we have a problem in that players realize that they're easy to make and will spam them.

I'm open to ideas on how to get players to value their characters more, and will start with proposing my own idea for how to do it.

Make it so captivity cannot be escaped by chance. Either your captor becomes captive (and you pass to the new captor) or they release/kill you. Captivity will either prevent you from killing your character, or massively up the spawn timer. The goal here is to tie up people who abuse the character setup, and at the same time, build up recognition between families and characters of those families that act in ways we want (not spamming characters to use as weapons).

Your thoughts please!

General Discussion / A Discussion On Allowing Non-Human First Ones
« on: February 22, 2018, 02:36:00 PM »
So, the topic has come up again and I'd be interested in hearing as much input on it as possible this time, as I'll probably not bring it like this again for quite a while (years?).

Should we allow First Ones to be non-human races?

Alternatively, should we allow people to say that they are playing elves, orcs, or other, pre-defined races?

I say pre-defined because it allows us to have specific descriptions of what the races look like in one place, and it means we won't get people coming in and just creating another race simply because they can.

Personally, I'm for it because it allows us to introduce a new dynamic into the social-aspects of the game. I will state though, this will be purely a cosmetic addition (if we add it). No sort of in-game bonuses or penalties regardless of whatever race your First One claims to be or actually is.

Your thoughts would be appreciated.

Announcements / December 2017 Report
« on: January 26, 2018, 11:55:47 AM »
Salutations Everyone,

Sorry about the delay in getting these out, but I had been focusing mostly on the upcoming update and life stuff.

As per usual, first, lets talk funding.

Income & Must Pays
(Keeping the Lights on)
Credit Purchases+105.00 EURHow much we received from players purchasing credits
PayPal Transaction Fees-3.05 EUREstimated Percent lost in fees to PayPal
PayPal Transaction Fees-3.00 USDPer Transation fees to PayPal
Hosting Costs-40 USDAmount spent on server hosting

Total= 84.09 USDMonthly Total
Leftover+ 28.17From Previous Month
YTD= 112.26 USDYear to Date Total

Like I mentioned last month, the joys of the credit system. It's not exactly predictable, but I'm not complaining.

What else would we, ideally, pay for though?

Additional Costs
(Things that improve the situation)
Advertising Costs-60.64 USDAmount spent on Google ads (Results will be broken down below)
Test Server Costs-40 USDAmount spent on the test server's hosting

Total-100.77 USD

As you can see, that costs a bit of money. The test server uses the exact same hosting plan as the live server, and has much of the same data, allowing us to push big updates to it first in order to make sure they don't catastrophically break something. It's not a required costs, but it's very much a nice thing to have. In regards to the advertising costs, that's got its own table below that goes more in-depth. These are the things I handle myself, as the game can't currently afford their cost.

Advertising Info
(New players are good thing)
TypeViewsClicksInteraction RateCost
Text Ad6,7683425.05%30.40 USD
Display Ad34,6047142.06%30.24 USD

Total41,3721,0562.55%60.64 USD

Like I said before though, this is something I've been paying for, myself, for quite a while now. From March of 15 through October of 16, I was paying for just a text ad. In November of 2016, I added the display (picture) ad. Lifetime, they've gotten 27,825 people to at least look at Might & Fealty.

Subscribers & Purchases
(What credits are spent on)
Subscriptions11,100 Credits
Heraldry1,500 Credits
Culture Packs0 Credits

Total12,600 Credits

How many players do we have though?

(How many gods?)
Count TypeAmountNotes
7-day142 Players
14-day154 Players
30-day169 Players

Based on that, the game has gained, as of this posting, 7 returning players over the last month and a half. Soon, I'll update the method I use to get this info so it does a lot of this for me, and shows me a better breakdown of info, but until then, this is what you're getting.

Announcements / November 2017 Report
« on: December 01, 2017, 03:37:17 PM »
Salutations Everyone,

I'm back again with the numbers from November!

If you're the type who's curious where the funds go or how much things cost, or even the condition of the game, well, here you go!

First and foremost, lets talk funding.

Income & Must Pays
(Keeping the Lights on)
Credit Purchases+15.00 EURHow much we received from player's purchasing credits
PayPal Transaction Fees-0.44 EUREstimated Percent lost in fees to PayPal
PayPal Transaction Fees-0.60 USDPer Transation fees to PayPal
Hosting Costs-40 USDAmount spent on server hosting

Total= -24.03 USDMonthly Total for November
Total+ 52.20From October
Total= 28.17 USDYTD Total

Well, it's certainly nowhere near last month. This kind of comes with the territory though, with how the credit system is setup. Sometimes players have a lot of credits, and sometime they don't.

What else would we, ideally, pay for though?

Additional Costs
(Things that improve the situation)
Advertising Costs-60.77 USDAmount spent on Google ads (Results will be broken down below)
Test Server Costs-40 USDAmount spent on the test server's hosting

Total-100.77 USD

As you can see, that costs a bit of money. The test server uses the exact same hosting plan as the live server, and has much of the same data, allowing us to push big updates to it first in order to make sure they don't catastrophically break something. It's not a required costs, but it's very much a nice thing to have. In regards to the advertising costs, that's got its own table below that goes more in-depth. These are the things I handle myself, as the game can't currently afford their cost.

Advertising Info
(New players are good thing)
TypeViewsClicksInteraction RateCost
Text Ad11,6363062.63%30.38 USD
Display Ad58,7728121.38%30.39 USD

Total70,4081,1181.59%60.77 USD

Like I said before though, this is something I've been paying for, myself, for quite a while now. From March of 15 through October of 16, I was paying for just a text ad. In November of 2016, I added the display (picture) ad. Lifetime, they've gotten 26,006 people to at least look at Might & Fealty.

Subscribers & Purchases
(What credits are spent on)
Subscriptions9,200 Credits
Heraldry0 Credits
Culture Packs0 Credits

Total9,400 Credits

How many players do we have though? I did say I'd share that this month. I will preface this with these numbers aren't as accurate as I'd like them to be, as the method I use to collect isn't ideal, but....

(How many gods?)
Count TypeAmountNotes
14-day147 Players
30-day163 Players

Is that what you expected? More? Less? I'll admit, I'm kind of curious.

Announcements / October 2017 Report
« on: November 10, 2017, 06:28:34 AM »
Salutations Everyone,

This will hopefully be the first of a series that will, normally, be done in the first few days of the month, as part of the game being a community project.

Some of you have been asking, where do the funds from the game go, how much does it cost, why subscriptions are still a thing, so I hope to answer that, along with any other future questions, here.

First and foremost, lets talk funding.

Income & Must Pays
(Keeping the Lights on)
Credit Purchases+85.00 EURHow much we received from player's purchasing credits
PayPal Transaction Fees-2.47 EUREstimated Percent lost in fees to PayPal
PayPal Transaction Fees-3.90 USDPer Transation fees to PayPal
Hosting Costs-40 USDAmount spent on server hosting

Total=52.20 USDMonthly Total for October

That's a fair amount of income, no? This is why I kept saying the game isn't actually doing bad. It's not doing great, but it's not dying.

What else would we, ideally, pay for though?

Additional Costs
(Things that improve the situation)
Advertising Costs-55.94 USDAmount spent on Google ads (Results will be broken down below)
Test Server Costs-40 USDAmount spent on the test server's hosting

Total-99.94 USD

As you can see, that costs a bit of money. The test server uses the exact same hosting plan as the live server, and has much of the same data, allowing us to push big updates to it first in order to make sure they don't catastrophically break something. It's not a required costs, but it's very much a nice thing to have. In regards to the advertising costs, that's got it's own table below. These are the things I handle myself, as the game can't currently afford their cost.

Advertising Info
(New players are good thing)
TypeViewsClicksInteraction RateCost
Text Ad11,8522972.51%25.53 USD
Display Ad61,4647981.3%30.41 USD

Total73.31610951.49%55.94 USD

Like I said before though, this is something I've been paying for, myself, for quite a while now. From March of 15 through October of 16, I was paying for just a text ad. In November of 2016, I added the display (picture) ad. Lifetime, they've gotten 25,244 people to at least look at Might & Fealty.

Subscribers & Purchases
(What credits are spent on)
Subscriptions10,400 Credits
Heraldry4,000 Credits
Culture Packs400 Credits

Total14,800 Credits

How many players do we have though? Well, I don't have an exact count at the moment, but I know how to get one. I'll put that information up next month, though, when I've got it properly integrated into the game's admin views.

Conduct & Design Discussion / Notes on the Conversation Bundle
« on: November 06, 2017, 12:51:17 PM »
To make a mark as read button...

Code: [Select]
   public function markRead (ConversationMetadata $m) {
      // find the conversation in question
      $qb = $this->em->createQueryBuilder();
      $qb->select('c, msg, meta')
         ->from('MsgBundle:Conversation', 'c')
         ->join('c.metadata', 'm')
         ->leftJoin('c.messages', 'msg')
         ->leftJoin('msg.metadata', 'meta')
         ->where('m = :m')->setParameter('m', $m)
            $qb->expr()->eq('msg.depth', 0),
            $qb->expr()->gt('msg.ts', 'm.last_read')
      $qb->orderBy('msg.ts', 'ASC');
      $query = $qb->getQuery();
      // set as read
      $m->setUnread(0)->setLastRead(new \DateTime("now"));

      // return true
      return true;

To make a mark as read for all characters button...

Code: [Select]
   public function markReadForMany (ConversationMetadata $m) {
      // get the actual conversation id.
      $found = false;
      $myconvo = $m->getConversation();
      // get the actual player.
      $user = $m->getUser()->getAppUser()->getUser();
      // find their characters.
      foreach ($user->getCharacters() as $char) {
         // get each characters conversations
         foreach ($char->getMsgUser()->getConversationsMetadata() as $convometa) {
            if ($convometa->getConversation() == $myconvo) {
               $found = false;
      if ($found)
         return true;
      } else {
         return false;

Theoretically, that's the logic for it, but it has a big problem in that this means it's going through EVERY conversation for EVERY character a player has. Which is incredibly slow.

What we need:

1. A way to limit the characters we're searching through.
2. A way to limit the conversations we're searching through.

I toyed with some logic for this below, but it's unfinished and I'm too tired to think straight so ignore it for now.

   public function markRealmRead (ConversationMetadata $m) {
      // get the actual conversation id.
      $found = false;
      $myconvo = $m->getConversation();
      $myappref = $m->getConversation()->getAppReference();

      $query = $this->em->createQuery('SELECT c FROM MsgBundle:Conversation c JOIN cmsg_conversation_meta m ON = m.conversation_id WHERE c.app_reference = :appref AND m.user in :cmsgusers);
      $query->setParameter('appref', $myappref);
      $query->setParameter('user', $cmsguser);

      $users = $m->getUser()->getAppUser()->getUser();
      foreach ($user->getCharacters() as $char) {
         foreach ($char->getMsgUser() as $cmsguser) {
            if ($convometa->getConversation() == $myconvo) {
               $found = false;
      if ($found)
         return true;
      } else {
         return false;

General Discussion / What is an Artifact worth? (In Credits)
« on: October 19, 2017, 04:12:40 PM »
Poll kind of says it all.

Conduct & Design Discussion / The 1.1 Update Topic
« on: September 30, 2017, 08:07:33 AM »
So, I need a place to keep my thoughts and work on this straight, and figured, why not do it publicly.

Here goes. Originally, this started at making palaces a thing. Then it expanded to making enterable features a thing. Then I thought, if I'm doing that, lets make customizable buildings (Places) a thing. And after that I realized that to make enterable features new types of settlements, which meant adding superior/inferior relations to settlements. Around that time I was thinking about how to build a new settlement, and figured, why not make it an inventory item. So I started working on adding inventories. In short, this update will be freaking huge.

Anyways, what I've got thus far:

Controller Changes:
  • ActionsController.php - Added routes for Place related actions.
  • ConstructionController.php - Minor Settlement Worker count variable passing to twig logic added to /buildings route. Added logic for not building certain things in cities.
  • MapController.php - Added logic for loading Places.
  • PlaceController.php - New. Has logic for viewing, and permissions, so far.
Doctrine Changes:
  • BuildingType.orm.xml - Add built_in, maps to SettlementType allows field.
  • Character.orm.xml - Add updated_places, maps to Place updater field.
  • Description.orm.xml - New file, tracks all relational data for Descriptions. Id, associated entity, text, timestamp, cycle, active, previous/next.
  • EventLog.orm.xml - Add place field, to allow places to have event logs.
  • FeatureType.orm.xml - Add upgrades_to one-to-many relation to SettlementType
  • GeoData.orm.xml - Add places relation.
  • Place.orm.xml - New, tracks name, type, description, descriptions, location, associated settlement, assigned soldiers, and permissions.
  • PlacePermission.orm.xml - New, tracks relevant permissions.
  • PlaceType.orm.xml - New, tracks different place types.
  • Realm.orm.xml - Add capitals, maps to Settlements; add permissions, maps to RealmPermissions.
  • RealmPermission.orm.xml - New, for future work later.
  • Settlement.orm.xml - Add capital_of, maps to Realms. Add superior/inferiors, maps to self. Will allow subordinate settlements. Add type, maps to SettlementType, will control what buildings can be built. Add places, maps to settlement on Place. Added description, updater (character), updated_on.
  • SettlementType.orm.xml - New, tracks allowed types of settlements. New fields for name, many-to-one relation on which features they upgrade, enabled boolean for turning new ones on or off, subtype string to tie into later roving clan system. Many-to-many field for tracking what buildings can be built where, homed off BuildingType table.
  • Solder.orm.xml - Add relation for soldiers being in Places.
DataFixture Changes:
  • LoadBuildingData.php - Added BuiltIn logic for new settlement types, added following buildings: Warehouse, Dockyard, Apothecary, Guild Square, Guild District, Empty Moat, Filled Moat, Quarry
  • LoadFeatureData.php - Added new feature types, added logic for adding new ones
  • LoadPlaceData.php - Add place types
  • LoadPermissionData.php - Add new place permission types. Added updater logic.
  • LoadSettlementData.php - Add settlement types. Not sure if these'll be used now.
  • Place.php - Shell File
  • PlaceType.php - Shell File
  • SettlementType.php - Shell File
  • Settlement.php - Added functions for finding minor settlement worker counts and percentages.
  • User.php - Added isVeryNewPlayer logic for quickly finding if a user is under 7 days old.
  • PlacePermissionsSetType.php - For setting Place permissions.
  • PlacePermissionsType.php - For setting Place permissions.
  • RealmPermissionsSetType.php - For future use.
  • RealmPermissionsType.php - For future use.
  • DescriptionManager.php - New file, for processing new descriptions.
  • Dispatcher.php - New logic for entering/exiting settlements button. Includes a getClassName function, that we'll want to move elsewhere later. Added placeManageTest, placeCreateTest, placePermissionsTest, placeEnterTest, placeLeaveTest. Renamed all existing $place to $estate as appropriate in order to differentiate them.
  • Economy.php - Update building conditions.
  • Geography.php - New findNearestPlace function, required for the Dispatcher. Added calculateDistanceToPlace function, for calculating the distance to a place.
  • Interactions.php - Added logic for visibility of details of places. Overhauled get_class_name to getClassName so it doesn't look like a PHP function but instead one we made. Also updated it and dependencies to have this method do more of the work, decreasing code size.
  • Military.php - Added logic for places having resupply options. Not going to be implemented now. Added getClassName method, for when we do implement it.
Symfony Files:
  • services.yml - Told Symfony2 how the DescriptionManager is supposed to interact with things. Will require further updates to tell other things that the descmgr is a thing.
  • communication.en.yml - Added event.description.update.stuff entries.
  • places.en.yml - Needs so many strings.
View Changes:
  • Construction/buildings.html.twig - Added in logic for displaying minor settlement building worker counts on building construction page.
  • Character/start.html.twig - It is now no longer possible to start on the map as a brand new player.
  • Place/manage.html.twig - New.
  • Place/new.html.twig - New.
  • Place/permissions.html.twig - New.
  • Place/view.html.twig - New.
  • Feature building form updates so it knows when something is available in inventory for placing. On hold for now.
  • Construction form updates so it knows that only certain things can be built in certain settlement types.
  • Logic for converting a building to an inventory item to a settlement/place -- Palaces will not be traditional buildings. This should include monuments, plazas, etc. On hold for now.
  • Logic for managing population between settlements in same region. Canceled.
  • Logic for Regional Lords to manage appointment of sub-lords. (Settlement law system, or Realm law system? Both?) Canceled.
  • Controller for Places? Or should we just build this into the existing Settlement Controller? Completed.
  • Update BuildingTypes with settlement type info. Completed.
  • Determine settlement types. Completed.
  • Update Doctrine config for building types to add type field. Completed.
  • Update Building DataFixture to load in new types. Completed.
  • Add separate logic for troops garrisoned other than cities/villages. All resource concerns should be routed through the primary settlement. Bypassed. Soldiers/noble never leave map, always have location, thus always have food cost.
  • Add conditions for construction of dockyards and filled moat. Dockyard on hold for now. Other conditions completed.
  • Add resource data for new buildings. Completed.
  • Add logic for Sublords? Perhaps with individual translation strings depending on what type of settlement it is. Canceled.
  • Add additional permissions for settlements about which buildings are usable and what information can be available in them. On hold for now.
  • Add logic for the game to understand not all settlements will have resources, and that many resource requests need to be routed through the superior settlement. Canceled.
  • Add permissions system to places. Completed.
  • Add permission to settlements to allow creation of places by other players. Completed.
  • Add logic for restricting certain place types. Completed.
  • Do we want places to build off the existing features system? This would bypass the requirement to modify the existing map viewer to display them. We'd have to modify how feature workers are handled though, and maybe even how they're displayed in order to make sure that places also display. Do settlements display as features if we assign them an icon? That's an interestingly related question, as settlements are TECHNICALLY map features. Hm. Completed.
  • Add logic for places being deactivated and inaccessible, so if, for instance, a capital was destroyed by one realm then later rebuilt, you can dig up records on the old on. On hold for now.
  • Add a service for descriptions. Completed.
  • Ensure settlement food requirements are setup to account for those in places. Not sure how the game handles that, so we should look into it. Bypassed. FOs never leave map.
  • Add routes to the action controller for entering/exiting places. Completed.
  • Add logic for only editing a place description/permissions if you're inside of it and the owner or have permissions to do so. Completed.
  • Add route for editing place description. Completed.
  • Add form for editing/creating places and descriptions. Completed.
  • Make sure we don't generate a description if we don't need to. Copy how character backgrounds (/background) work. Might have to differentiate the active description and all descriptions to get this to work right. Completed.
  • Add route for creating new places. Completed.
  • Dispatcher needs checks: hierarchyManagePlaceTest; Completed.
  • Add list for PlaceManageType to use to know what places can be built where. Completed.
  • Add menu & page & controller route for selecting realm capital. Completed.
  • Add literally every translation string, almost.
  • Add hierarchySelectCapitalTest to Dispatcher. Completed.
  • Detach placeManageType from the Place Entity when managing an existing place.

Announcements / "To Your Positions" Update!
« on: September 29, 2017, 05:55:15 AM »
We are pleased to announce that the 1.0.3 Update, "To Your Positions", has gone live. Along with some major back-end changes, we're pleased to announce the following new features and fixes:
  • A new method for handling realm conversations has been implemented.
  • There are now 2 default realm conversations, one for Announcements, like elections, and one for general discussion.
  • Unfortunately, due to how these are handled, all realms will see 2 new conversations added to them, but...
  • The groundwork has been laid for allowing you to customize what messages go to what conversation (on the backend, at least).
  • Elections will only be announced in the announcements thread! No more election spam. Which is good, because...
  • Ruler positions that have an election type set will now use that election type when an election is needed and...
  • All election types are fully implemented.
  • All other positions will be inherited or have an election, as appropriate, when the positions is vacated due to death/slumber.
  • Positions will inherit first, if able, then go to an election, if able.
  • Positions have set election dates, expressed in Years and Weeks.
  • All positions are elected on the first day of that week, in an automated election.
  • Elections are now handled as part of the turn system, rather than when the election list is loaded.
  • This means that the vote count times are now 100% predictable.
  • Elections will now trigger again after 7 days, down from 15.
  • Previous position holders will lose their position only after the election completes, but before the winners are chosen.
  • Positions can be designated as having more than 1 minimum holder, which the game understands is the target quantity of holders.
  • New election type added: "by fortifications" that counts vounts based on the fortifications in a person's settlements.
  • Add election sub-types for "by land" and "by fortification" to only include land in the realm.
  • NOTE: Ruler positions will always cause an election if they aren't inherited! This election will use the set election type.
If you encounter any errors, please let us know ASAP so we can fix them! Thank you!

Conduct & Design Discussion / Activity & Activity Buildings
« on: September 10, 2017, 07:43:24 PM »
So, it occurred to me that I could load the buildings in now, before all the code that will be attached to them, for the activity-centric structures.

This will be things like Jousting Grounds, Solo Match Rings, Free for All ranges, etc., but I'm kind of on the fence about how I want to implement them.

They will have buildings associated, at least for the major ones--jousting grounds are drastically different setups than say, a fencing hall.

But I'd also like to know what activities you'd like to see added, so please, share your ideas here. Both on what the activity is, how it'd work, and what building(s) you'd need for it.

Oh, feel free to discuss what skills you think would affect everything as well. ;)

Conduct & Design Discussion / M&F Changelog
« on: August 21, 2017, 02:46:16 PM »
Curious how things have changed over time? Look no further! This version tends to be a bit more technical sounding than the one in game, but also tends to include things not relevant to play (like back end stuff, which I don't mention unless it's a significant part of the update.)

Version 1.3 (pending)
  • Sieges
    --Sieges involve special equipment that is constructed on site and deconstructed (or destroyed) after a siege ends.
    --Settlements under siege may mass levy a third of their populous to defend the settlement, but levies are untrained, less effective, and break far more easily than professional soldiers.
    --Levies may use improvided weaponry or have no armor, but may have either if available.
    --Levies automatically return to civilian work afterwards, returning any gear they had.
    --Sieges will cause settlements to consume food at a significantly reduced rate, take longer to starve, but also completely halt all resource production.
  • Siege Equipment
    --At this time, you have battering rams, ladders, ballistas, catapults, trebuchets, and siege towers. Some of these can be constructed by both sides.
    --Siege equipment that goes against the walls will have "contact points". Mechanics of these will be below.
    --Once complete, ranged siege weaponry will automatically start firing at the opposing force.
    --At this time, it will not be possible to transport these with you, though they won't take much time to make.
    --A given soldier is only worth one quarter of a soldier when constructing siege equipment, as it is assumed their time is divided between several tasks throughout the day (sleeping, eating, standing watch, patrolling, manning existing equipment, etc.).
    --Exact construction times will be on the manual in the coming days.
    --There is no point to construct more equipment than your force can use, as at this time there is no means to transfer it. Manpower requirements will be on the manual prior to release. And similar to construction, only 50% of your soldiers will be able to man siege weaponry before an assault.
    --During assaults, ranged weaponry will be abandoned for ladders and towers to be brought forward. This will take a couple rounds.
  • Siege Battles
    --Assaults on the fortifications will be greatly assisted by actually damaging the walls. Assaulting an undamaged, high class wall is probably not a smart move.
    --On that same note, it is possible that a significantly smaller force will hold off a much larger attacking force.
    --The effectiveness of archers around just Palisades will be greatly diminished on both sides (defenders will be in cover and attackers won't be readily visible to aim at)
    --The effectiveness of archers around proper walls will be varied. Defenders will be harder to hit, while attackers will be more likely to hit.
    --Your ability to attack the enemy depends on your number of contact points. If you can force a total wall collapse as the attacker, I highly recommend it.
    --Contact points affect attackers ability to attack in melee. Defenders always get 1 more opportunity than attackers, per individual contact. Ladders will provide 1 contact point each, while siege towers will provide 4.
    --For each attacker that survives a melee in a round, contact points will increase by 1. This simulates the attackers managing to take the walls.
    --For each attacker kill on the walls, contact points will decrease by 1, to a minimum of what the siege equipment provides. This simulates the defenders managing to push back.
    --Heavily damaged walls will offer bonus contact points, as they'll be considered breached. The level of breach, and number of contact points offered, will vary by wall damage level.
    --Archers are, naturally, unaffected by breach points.
    --At this time, what soldiers are near what ladder is not taken into account.
    --Walls offer a far less significant benefit to defender morale--similar to being in their home region. Walls (not palisades), now instead decrease the likelihood of defenders to be hit by ranged fire.
    --Damaged fortress and citadels will offer similar benefits/penalties to damaged walls, though will take a significantly harder beating.
  • Battles (in general)
    --The game will now distinguish between the terrain of a battle, and certain areas will offer certain penalties, primarily to ranged soldiers at this time.
    --Urban (those in a settlement) and forest battles will suffer general penalties to archers, with archers in a settlement simply not being able to find a target, while those in the forest unfortunately hitting trees.
    --Battles involving a siege are covered above.
    --Morale is a bit more resilient overall, but will take hits (or boons) if first ones die in combat or retreat.
    --Forces facing foes of roughly the same size (+/- 30%), outside of sieges, should start roughly even on morale. Outside of this, there will be penalties on the smaller force. Sieges are not affected by this as much.
    --Soldiers will naturally have higher morale in their home region, whether attacking or defending.
  • Unit Settings
    --Archers will no longer automatically only hit enemies when firing into the melee. As such, you can order them to avoid this via unit settings (please note, there's still a VERY small chance they'll still hit an ally, if they don't completely avoid it).
    --You can either order them to avoid ranged combat altogether, pick safe targets only, or fire at any target. Avoiding ranged makes them a melee combatant, while picking safe targets will reduce their likeliness to hit, but also make their chance of hitting an ally basically non-existent. The last option, gives an archer a base 20% chance of hitting an ally during any phase involving melee. This can be downplayed somewhat by experience.
Version 1.2.3 (pending)
  • Sieges
    --Sieges have entirely replaced the prior system of settlement battles.
    --To attack a settlement you must declare a siege.
    --Sieges will suspend all trade in a settlement while it is active, if there is enough besieging soldiers to encircle (normally, a couple hundred is sufficient).
    --Sieges do not prevent soldier training or food collection, just population growth and trade. This is predominantly a balancing thing in order to keep the defenders from getting steam rolled until we update the actual battle mechanics.
    --Citizens under siege won't care about jobs that don't produce food, weapons, or armor, freeing up more to find whatever food may be hiding in the settlement. Again, a balancing thing, though this will stick around.
    --Trade coming to a besieged settlement will be considered lost, while trade going out from a besieged settlement will be suspended (meaning it can use it in the interim).
    --Sieges will suspend all automated entry of a settlement, as well as prevent people from leaving.
    --Sieges have commanders, and build on the existing battlegroup system.
    --Lords of a besieged settlement, if inside it, can assume leadership of their battlegroup.
    --Whoever declares the siege on the attacking side will automatically assume leadership.
    --Leadership of a siege allows you to either assault or sortie en masse, or to transfer the leadership to someone else.
    --For now, food levels of settlements under siege will not be modeled. This will come later, if we think it's necessary.
  • Siege Battles
    --Settlements under siege have new battle mechanics. Namely in that assaults and sorties have different effects on bonuses.
    --Assaulting the walls will force a slight morale penalty on the defenders, though their morale will drop slower as they defend what is theirs. Defenders will receive defensive bonuses.
    --A sortie from the walls will force a slight morale penalty on the besieging force, as they will be less prepared, unless an assault is already pending, as the besiegers will be in some disarray. No side will receive defense bonuses.
    --Sieges may not be over after one battle. If a settlement possesses a castle, fortress, or citadel, there will be multiple successive battles as the settlement is overtaken.
    --Palisades, Fortress and Citadels both offer an additional "take the walls" battle each, while a castle provides a "storm the keep" battle.
    --On the flip side, the besieged, should they sortie, shall have "retake the city" battles and a final "break siege" battle.
    --Defenses offer bonuses to siege defenders depending on where along in the siege you are. As the city is overrun, defenders will get fewer bonuses, as you exterminate their ability to resist.
    --Palisades/Walls, Fortresses, and Citadels all make defenders significantly harder to hit with ranged fire. We recommend shields.
  • Battles (in General)
    --It is no longer to attack someone inside a settlement without leaving the settlement. If you try, the game will move you out automatically.
    --If you are inside a settlement and try to attack people both outside AND inside, it will prioritize those inside, and not engage anyone outside.
    --You no longer receive defensive bonuses when fighting inside a settlement, only when you are defending from an assault.
    --Whether or not you get experience when fighting someone who is slumbering is now dependent on the ratio of characters that are awake to those that aren't.
    --Terrain now affects your ability to hit your enemy. Forests, especially dense forests, will greatly hinder ranged accuracy, as will fighting in settlements.
    --If you join battle preparations late, you join battle late. For each quarter along the battle preparations are, your force will join a round later, starting with the second round at 25% progress (ranged round is always free).
  • Battle Reports
    --Battle Reports have been overhauled in order to allow for additional flexibility in the number of groups per side of battle.
    --Additionally, they'll also tell you exactly how your character did. But not other people, because you were too busy fighting to notice.
    --Your soldiers will also let you know how your force specifically did.
  • Permissions
    --You can now, 100%, verify which characters you're granting permissions to. On all list entries the game will tell you the specific ID of the character.
    --On a related note, assuming he were still alive, the following are all valid character name entries almost anywhere the character search system is used: "Bear", "Bear (ID: 3)", and "3"; the exception being when writing a message. Still have to do the [c:3] there.
    --If you want to be absolutely sure, include the ID and the game will understand that you're looking for an exact match.
  • Characters
    --You can no longer include numbers or most special characters in names, in Character names.
  • Unit Settings
    --You can now select a supply point for your soldiers to draw food from. This can be either a settlement you control, one that your lord has granted you permission to use, or one that you've requested and received permission to use.
    --NOTE: Soldiers will still draw on local supplies from where they are on the map until the next update. We are not setting anything for you, and once the next update hits, if your soldiers starve, that's on you.
  • Settlements
    --A new permission has been added that will allow your knights to be able to feed their soldiers from your settlement(s).
  • Game Requests
    --You can now formally request permission to have your soldiers feed off the supplies of any settlement in your realm for a potentially limited duration.
    --These requests will be considered void if a new lord takes over, though the game won't reset your settings if you are that new lord.
    --You can now view ANY request pending or currently active that involve you, your settlements, your places, your house, or your realms.
    --Logic was added in to handle Places, as we'd like to get them added in one of the next few updates.
  • Page Routing Upgrade
    --The game is now smart enough to know it shouldn't send you to the login page when it's confused. It'll send you to an appropriate location if you request a page you shouldn't have access to given your current game state.
    --In other words, if you're not logged in, you get the login screen. If you need a character selected, but don't have one, you get the character select screen. If you have a character but they're not able to access that screen, you go to character status.
    --This involved adding to most pages what I find to be a personally amusing line of code that amounts to: "If security returned a character that is NOT a character then I should reroute the user to whatever route matches this not-character that security gave me"
    --Other pages are handled by a less complex security that just sends the user to login, so don't require that amusing code.
  • Back-end Services
    --A single function of ActionResolution was moved over to a new ActionManager, to make things less dependent on ActionResolution in order to allow other things to be dependent on it.
    --A number of functions of ActionResolution were moved over to WarManager
    --A few functions of Military (now renamed MilitaryManager) were also moved to WarManager
    --GameRunner has been taught how to remove expired GameRequests.
    --The game now understands that settlements are settlements, and when fetching them, an estate is not a settlement. I know this sounds like an afterthough, but we're talking about like 200+ separate instances in 40+ files that got changed.
Version (20190103)
  • Characters in battle are no longer able to be played until the battle completes. This will hopefully mean battles will run properly more often.
Version (20181206)
  • It is no longer possible to play a character while the turn is running. This will hopefully mean battles will run properly more often.
  • Automated elections now last for a week, rather than 3 days.
Version (20181130)
  • Position descriptions now properly use markdown like most other text fields in the game.
Version (20181125)
  • An exploit involving gifting credits was fixed.
Version (20181009)
  • Retired characters will no longer prevent characters being created
Version (20180916)
  • Action resolution command now commits changes to the database after completion.
  • A military_intercepted function was added to the ActionResolution service in order to allow proper handling of the military.intercepted event type. This action is now only removed when a character is no longer in any battle whatsoever.
Version (20180912)
  • Abductions are now less effective outside of a settlement's walls, and a cooldown system was implemented in order to make this possible.
  • When a settlement collapses, it'll no longer drop fortifications unless it's already dropped everything else.
Version 1.2.2 (20180905) - "Staging Sieges..."
  • Added Unit Settings entity and doctrine config files.
  • Added "Battle Setup" page for configuring personal Unit Settings.
  • New manual pages for Units and (future) Battles.
  • Fixed translation string for Realm Descriptions.

Pages: [1] 2 3 ... 15