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
1
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)
TypeAmountNotes
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)
TypeAmountNotes
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....

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

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

2
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)
TypeAmountNotes
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)
TypeAmountNotes
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.

3
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)
         ->andWhere($qb->expr()->orX(
            $qb->expr()->isNull('msg.id'),
            $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) {
               $this->markRead($convometa);
               $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 c.id = 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) {
               $this->markRead($convometa);
               $found = false;
            }
         }
      }
      if ($found)
         return true;
      } else {
         return false;
      }
   }

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

5
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:
  • ConstructionController - Minor Settlement Worker count variable passing to twig logic added to /buildings route.
  • PlaceController.php - New.
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, location, associated settlement, and assigned soldiers.
  • PlaceType.orm.xml - New, tracks different place types.
  • Realm.orm.xml - Add capitals, maps to Settlements.
  • 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
  • LoadSettlementData.php - Add settlement types. Not sure if these'll be used now.
Entities:
  • 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.
Services:
  • DescriptionManager.php - New file, for processing new descriptions.
  • Dispatcher.php - New logic for entering/exiting settlements button. New logic for entering and exiting places, and all the checks to see if you can.
  • Economy.php - Update building conditions.
  • Geography.php - New findNearestPlace function, required for the Dispatcher.
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.
Translations:
  • communication.en.yml - Added event.description.update.stuff entries.
View Changes:
  • Construction/buildings.twig.html - Added in logic for displaying minor settlement building worker counts on building construction page.
  • Character/start.twig.html - It is now no longer possible to start on the map as a brand new player.
TODO:
  • 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? Definitely a separate controller for places.
  • 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.
  • 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.
  • 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.
  • Add permission to settlements to allow creation of places by other players.
  • Add logic for restricting certain place types.
  • 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.
  • 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.
  • Add a service for descriptions. Completed.

6
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!

7
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. ;)

8
Conduct & Design Discussion / M&F Changelog
« on: August 21, 2017, 02:46:16 PM »
So, it seems the bugtracker wasn't doing it how I hoped it would, so I'm going to try and include a changelog here so people can see what was added when:

Version 1.0.4.5 (20171211)
  • Changes to how events are displayed were rolled-back to the original code for displaying events as it caused an issue in how scholars are handled that prevented you from assigning them to research events. :(
Version 1.0.4.4 (20171127)
  • A bug in how elections were handled when due to close has been fixed. Elections are now smart enough to see if a position is involved before trying to remove positions that don't exist.
  • More logging in election handling was added.
  • A bug in knight offer message generation involving trying to put an entire realm into a message was fixed--we told it to only pass the ID of the realm instead.
Version 1.0.4.3 (20171106)
  • A bug in the routine election handler that didn't update the position cycle counter correctly has been fixed. This may be the reason for routine elections getting called again so soon.
  • We've figured out how to reorder the map layers in order to get it to display like it used to. The super weird part is that we have no idea how it was working on Tom's server before this, because we were, previously, using the same files.
Version 1.0.4.2 (20171103)
  • Fixed a bug caused by the liege of a knight offer acceptee also being a welcomer.
  • Knight Offer conversations are smarter, and will reword slightly if welcomers are present.
  • New manual page for Realm Positions.
  • Re added manual page for the Test Server.
  • Reworked some links for consistency and professionalism.
Version 1.0.4.1 (20171024)
  • The new election type was mistakenly not added to the election types list in the realm position editing menu. (Maybe we should store this in a single place?)
  • A bug in the positions system involving objects not being strings (when expecting a string) has been fixed.
  • An oversight in some code involving election incumbents being removed has been corrected, meaning less time will be spent removing incumbents. Previously, the game would try to remove people from a position it already removed people from. There is no need to repeatedly remove no one from a position.
Version 1.0.4.0 (20171023) - "Welcoming Committee"
  • Realm Positions can now be flagged as Welcomers.
  • Welcomers can be attached to Knight Offers.
  • Knight Offers with Welcomers will include those Welcomers on the intro conversation.
  • Knight Offers can only be made in settlements that have a realm.
Version 1.0.3.7 (20171023)
  • A bug causing elections when the election year/week was set to null or 1 has been fixed. (The game treats 1 as null when saving in order to bypass some Symfony silliness about null integers.)
Version 1.0.3.6 (20171021)
  • Voting method "by horses", added at the request of discord user Vammy#6426.
Version 1.0.3.5 (20171018)
  • Fixed the last couple spots in the code that required a mail spool to function right--the game now checks to see if a mail spool is set, uses it if one is, or doesn't if there isn't.
Version 1.0.3.4 (20171016)
  • A problem in how the game handles forms and passing integers to/from them in relation to Realm Positions was worked around. A null value in one of these fields now submits a 1. Anytime the year for a position is set to 1, the RealmController will assume the player set a null value, and then update the position to set these values to null (something the form itself won't allow, irritatingly enough).
  • A bug that prevented incumbents from being removed from positions after the completion of a routine election was fixed.
Version 1.0.3.3 (20171007)
  • Routine elections will no longer report the elected position as that of the ruler, unless it was in fact a ruler election.
  • Settlement population will no longer show up on the map.
Version 1.0.3.2 (20171006)
  • The bureaucrats have been told they need to report to the priests (for relay to the Gods) more thoroughly on all the dead First Ones. (We added more debug info to turn changes)
  • They're also a little smarter about all of that stuff in general.
  • Longbowmen will no longer use javelins as ammunition.
  • Only thy lord shall knoweth thou total population.
  • A typo that created an incorrect event log has been fixed.
  • A typo that froze the game's turn processing logic has been, hopefully, corrected.
Version 1.0.3.1 (20171005)
  • A bug we introduced while making it so we could ban cheaters was fixed, allowing you to gift credits to players once again.
  • Elections are smarter about when they should be called, and are smart enough to know when a position has already had an election called.
  • A counter involved in numbering of elections, that forgot how to count, was taught how to count.
  • Elections no longer care about finding realm members. This was a holdover from older code that used to handle all of this for Ruler changeover.
Version 1.0.3.0 (20170929) - "To Your Positions"
  • Ruler positions that have an election type set will now use that election type when an election is needed.
  • 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.
  • Positions have set election dates, expressed in Years and Weeks.
  • All positions 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.
  • 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.
Version 1.0.2.9 (20170907)
  • A bug introduced by a Symfony update (2.7.7 -> 2.7.33) that prevented character grouping reassignment has been fixed.
Version 1.0.2.8 (20170906)
  • A fix in the code that prevented dungeon and subscription processing has been applied.
Version 1.0.2.7 (20170821)
  • Some code that generated errors in the economy handler has been deactivated. It didn't do anything.
  • Characters with partners/parents that don't have crests can once again select a crest.
  • A bug involving a typo with the "dungeonEventFilter" has been corrected.
  • Dungeon DataFixture tables were altered to detect whether an entry was new or already existing when loading them in, allowing new entries to be loaded without messing up existing ones.
  • As such, 25 new monsters and 1 new card are now, FINALLY, actually in the game.
  • Nearly all travel blocking actions now show up on the character select page.
Version 1.0.2.6 (20170802)
  • Bandits are far less likely to spawn on icecaps.
  • Bandits will no longer spawn with plate armor, broadswords, or warhorses.
Version 1.0.2.5 (20170709)
  • A tool was added to ban cheaters.
  • In order to assist testers, the game is smart enough to figure out which server it's running on and change the page title accordingly.
Version 1.0.2.4 (20170618)
  • Non-functional BitPay functionality was removed.
Version 1.0.2.2 (20170608)
  • Map loadlist no longer appears on realm pages, improving usability for smaller displays.
Version 1.0.2.1 (20170608)
  • Heraldry can now be shared between partners and to their children. It is no longer account specific.
Version 1.0.2.0 (20170603)
  • Several hundred lines of code for an alternative message system were removed, making the game's code repository fully functional without additional work.
Version 1.0.1.2 (20170520)
  • Inactive subrealms can now be restored.
Version 1.0.1.1 (20170424)
  • Slumbering first ones no longer grant experience
  • Realm info can be viewed without being logged in
Version 1.0.1.0 - "Community Takeover Build"
  • Added ability to exit settlements
  • Realm elections once again trigger for absent rulers
  • Link to wiki added
  • Publications & Positions can be linked in-game
  • Economic security can no longer be viewed at a distance
  • Dungeon framework and language errors were fixed
  • Most tables are now sortable.
Might & Fealty version 1.0.0.0 - This is where the community took over from.

9
Announcements / Server Move: Successful!
« on: August 20, 2017, 01:44:43 PM »
We are pleased to report that the server move went incredibly smoothly, and that all interaction with the game is now on the new community run server.

You should notice a number of fixes and additions detailed on the in-game announcements you'll find on the character list.

If you encounter any errors, please let us know, either here on the forums or on the bugtracker linked in-game.

Thank you!

10
General Discussion / Things to Do
« on: August 01, 2017, 01:23:03 PM »
So, I'll admit, I'm still with Tom on keeping M&F a game that you can actually play in a few minutes a day. But, I understand there are people who want more things to do in game.

So, lets hear some ideas.

11
General Discussion / Fixing Evasion
« on: August 01, 2017, 01:16:00 PM »
The evasion mechanics are broke, and I took some time to look at the code for how this works and think I have a decent understanding of it.

Since battle isn't my forte though (I'm more a builder/roleplayer), can someone run me through what actually happens and what the problem is.

After that, lets take a moment to figure out how to fix it. I'm pretty sure I've got an idea, but I need to make sure we're all on the same page on this.

12
General Discussion / The Value of Experienced Soldiers
« on: August 01, 2017, 01:10:14 PM »
So the topic was brought up, and discussed, and eventually derailed, but how do we make soldiers valuable in and of themselves?

Higher experience troops should have value more than just doing slightly more damage. I'm toying with the idea of making them SLIGHTLY more survivable, but part of me likes the fact that a recruit, a veteran, or a first one all take a serious wound when they take an arrow to the eye.

We could expand the existing capture system for first ones to include more experienced soldiers, maybe assign them ranks based on experience gained, and make it so that you can store prisoners in cities (something I was already debating). You could then use them as bargaining chips between realms.

13
Announcements / Server Move Scheduled: 19 August
« on: July 31, 2017, 05:46:03 AM »
Hello everyone!

Tom and I are planning to move the game to my server on 19 August.

Along with a number of new updates, this server will be exclusively hosting Might & Fealty, and will fully enable the community to continue developing the game as we see fit.

14
Conduct & Design Discussion / The Next Big Change: Buildings
« on: July 09, 2017, 04:45:26 AM »
So, you might be thinking, we already have buildings, and they work, so why would you change them? Well, they do work, but with a lot of aspects of Might & Fealty, they strike me more as a skeleton lacking meat than a fleshed out design.

There are, at present, 53 types of buildings, focusing primarily on military or things that support the military. And you can only build them once, and from there their use is abstracted: more people in the city, more tailors, more smiths, all from one "smith". Yes, Might & Fealty is a military simulation, but it's also simulates other things, like medieval politics and nobility. And I know that there are a good number of players that do or have previously played specifically for the building aspect of things.

Here's what I propose:
  • Expand the build list -- Simulate more of what's present in a given city, modeling everything from the number of Inns to the Mints t the Jousting Fields to the Wells at the end of the streets.
  • Repeatable builds -- Allow players to control how many of a given building exist in a city. This will also allow the game to better understand how the layout of a given city, and may even allow us to do such things as modeling a city based on the number of roads that  go through gates in it's walls, and how that plays into an attacking force besieging the city. Certain things, like walls, will naturally cost MUCH more each time you build them.
  • Optional Autobuild -- Give players the option to disable the autobuild aspect. Buildings will still rely on other buildings (or the resources they put out) but maybe you just want that personal touch?
So, that covers my goal, and some of the why, but what are my other reasons?
  • It increases the amount of abstract modeling we can do on what a city may or may not look like. If you have 3 gatehouses but 5 roads that go to your city, we can assume there's a perimeter road outside the walls.
  • It lets us build other changes off of this. When player complexes are added, you could associate parts of those with specific buildings, allowing you to add flair to your city. When unit groupings are something managed through a barracks or garrison, allowing repeatable builds makes it super easy to figure out how many groups you should be able to field.
  • It also means we could even go so far as allow you to name buildings or statues or give them in-game descriptions.
  • Lastly, when you can build things outside a settlement, it means we don't have to reinvent the wheel for what the building system allows, but just reinforce the wheel we've already fixed.
Now, I'd like to hear your feedback on this. Should every building be repeatable? Which ones shouldn't? Why or why not? Is this just a horrible idea? What buildings should be added to really flesh things out?

15
Conduct & Design Discussion / Equipment Overhaul
« on: June 16, 2017, 07:56:06 PM »
So, I'd like to start working on this as I'll be tinkering with how soldiers handle their equipment in the coming days anyways. This is what I'm thinking things could look like in their next phase:

Melee Items (Weapons):
  • Club - Think "improvised weapons"
  • Axe - Bonus against wood shields
  • Peasant Flail - Purely wooden, more powerful than a club. Cheap, breaks easily.
  • Spear - Bonus against cavalry
  • Pike - Like halberd, but no defense boost
  • Halberd - Mostly offensive, but slight defense boosts, bonus to dismounting targets
  • Mace - Bonus against plated armors
  • Sword
  • Morning Star - A mace with pointy bits, no more bonus, but better overall (even when accounting for the mace's bonus)
  • One-handed Flail - "Ball and chain" weapon, that can harm it's user when it misses. Powerful though.
  • Broadsword
Ranged Items (Weapons)
  • Slings - Super cheap, not very strong at all though.
  • Shortbow - Small bonus on horseback
  • Javelins - Double as a melee weapon in a pinch. No longer single use.
  • Crossbow - Single shot if mounted.
  • Longbow - Small penalty on horseback
Armour (in order of defense provided)
  • Cloth Armor - Light Infantry
  • Leather Armor - Light Infantry
  • Scale Armor - Medium Infantry, no more metal requirement
  • Chain Mail - Medium Infantry
  • Mail and Plate - Heavy Infantry
  • Plate Armor - Heavy Infantry
Mounts
  • Saddle Horses - Really, more intended for work on a farm than part of a military.
  • Coursers
  • War Horses (Destriers) - More likely to survive blows
  • Camels - When we introduce larger scale deserts.
  • ?Elephants? - Very powerful, VERY dangerous.
Equipment
  • Round Shield - Cheap, wood shield.
  • Kite Shield - Standard, wood shield.
  • Heater Shield - Metal shield.
  • Pavise - Bonus against ranged attacks for infantry, no bonus in melee. Infantry only.
  • Dagger - Replaces short swords
  • ?Bandages? - Increases recovery chance
I'm open to further suggestions as well, and would like to include an initial rollout of advantages/disadvantages with this, as well as having mounts be separated from general equipment.

Pages: [1] 2 3 ... 15