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.


Messages - Andrew

Pages: [1] 2 3 ... 104
1
Conduct & Design Discussion / Re: New Permission System Design
« on: October 13, 2017, 01:30:49 PM »
I'd not even make that setting use the existing lists system. It'd be far simpler to jsut have the game do something like "if (in_array($settlement->getLord()->getUser()->getCharacters(), $currentcharacter) { allow } else { deny }". If I'm understanding the code right, I think that logic would be part of this function: https://github.com/Zanaras/MaFCDR/blob/master/src/BM2/SiteBundle/Service/PermissionManager.php#L52, along with an update to the form used to select settlement permissions to allow that as an option. We would possibly also want to make that a user profile selectable, so there could be a default setting for players to have when taking over a settlement.

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

2
General Discussion / Re: Discussion - Subscription Levels
« on: October 13, 2017, 01:15:09 PM »
If realms cost upkeep, it won't be while I'm running the server.

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

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

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

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

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

A multi-sub system would be... interesting, though I fear confusing. Right now it's a question of subscribed or not. If there are multiple mini-ones, it's a question of subscribed or not, if yes, which ones.

3
General Discussion / Re: Discussion - Subscription Levels
« on: October 12, 2017, 10:22:09 AM »
It is theoretically possible for me to figure out what most of M&F income actually is.

I'm loathe to go microtransactions, but if that's what most people spend money on (likely), and it'll still support the cost of the game's server, I can bring it up with Tom.

It's also something I'd want to ask the player base at large what their thoughts on it are, especially those who are presently subscribing.

4
Conduct & Design Discussion / Re: New Permission System Design
« on: October 12, 2017, 10:14:42 AM »
I'm on the fence about a hidden "my characters" list, because I can imagine people using it, and people not using it, in different situations. I don't think it'd be hard to code, though, without creating a hidden list--just add a check in the dispatcher somewhere to check to see if this character belongs to the same user. The only downside is that you'd have to add it to EVERY place permissions are checked.

That said, we could make it a settlement option to allow same user characters entrance. Or we could make it a player setting that each user can toggle.

5
General Discussion / Re: Discussion - Subscription Levels
« on: October 10, 2017, 01:51:01 PM »
The game was 100% paying for it's own hosting before the move, and then some. As it stands right now though, all income goes to Tom, mostly because I've not gotten around to changing the PayPal API so I can receive the income then transfer the income-after-deducting-costs to Tom. It's also a discussion I need to have more thoroughly with him sometime, about what he wants done about all that and what I can spend on what.

A lot of the life in this game was lost due to lack of development and server issues. I can pretty easily get an email to anyone who ever played for longer than like 2 weeks, but that's a one-off thing if I do it. I'd want to give those returning players something that was truly interesting to return to--which is hard when I'm the only coder that is contributing (in the sense of the game is running code made by someone) to the game. That said, if you know people who left who would have good input, I'd love to hear their thoughts on things.

I have been wondering though, people may choose to make multiple accounts because they can't afford the game themselves. Would it be worth it to add ways for players to earn credits or subscriptions? The game already has volunteer subscription levels in the code that I added should I decide to reward someone for helping.

6
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: October 10, 2017, 09:43:09 AM »
I always thought of it as the addition of burning oil and stuff or provide salves for wounds.

7
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: October 10, 2017, 06:02:43 AM »
If memory serves, I added moats and apothecaries. I may remove the defense bonus from apothecaries and give the full 10 back to alchemists.

As to why moats, because they're a real thing?

8
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: October 08, 2017, 08:59:09 AM »
Got some more work done on this. Rebalanced about half of the building defense bonuses in order to add in a few new types without making settlements even harder to crack.

Hopefully, what I've got done thus far will work as is, but all this will be hard to test without it all being there, so this will probably involve a LOT of fixing once everything is there and we start plugging it into the test server.

9
General Discussion / Re: Why M&F peaked so young
« on: October 07, 2017, 09:53:50 PM »
That's doable, we'd just need to decide on the distance or rules. You could do distance, or current realm they're in, or any number of things. (Yes, it is possible to find the current realm someone is standing in.)

10
General Discussion / Re: Why M&F peaked so young
« on: October 07, 2017, 07:33:51 AM »
I've been toying with a system for another thing of mine that would enable people to have conflicting information, but it'd be non-trivial to implement on M&F.

That said, I do like displaying the knight offers on the public map, but I don't think it's as trivial as just adding a line to map.js to load knight offers. I tried this, it did nothing. Might have to set the game up so that if you're not logged in it redirects to a different map, rather than the one used everywhere else. If we did that, then it should be pretty easy to load up knightoffers. Map.js needs some rework anyways, as there's no reason to load roads on the char start screen.

That said, I do agree with De-Legro. It's too easy to know things. Only lords shall know total populations of settlements at a glance. This should make it FAR more interesting for collecting taxes. It may also encourage or discourage town halls (which maintain the stats on population).

11
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: October 05, 2017, 12:21:01 AM »
Figured a way to do this without inventories, which should cut down the implementation time.

12
Conduct & Design Discussion / Re: The TODO & Concept List
« on: October 04, 2017, 10:46:16 AM »
Tallying votes, depending on the type of vote, would reveal a lot of info about a realm in a way that I'd prefer I not do. And to make a response to a discord conversation about it, if you want to know how many troops you have active in your realm, accept that it'll be public or just ask.

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

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

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

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

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

13
General Discussion / Re: Why M&F peaked so young
« on: October 01, 2017, 09:23:27 PM »
I'm refering mostly to this topic here: http://forum.mightandfealty.com/index.php/topic,6035.0.html

14
General Discussion / Re: Why M&F peaked so young
« on: September 30, 2017, 08:10:03 AM »
The game actively encourages players to start in active realms. Theoretically, that means new players should be interacting with players to learn these things before triyng to strike out with a character to take land.

That said, I'm not against an erosion system. I don't think one would be hard to implement either.

I'm also no against changing the new player introduction system, but I think I'll put that off until I flesh out the feature list a bit.

15
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:

Entities (New):
  • Place.php - Shell File
  • SettlementType.php - Shell File
Doctrine Changes:
  • BuildingType.orm.xml - Add built_in, maps to SettlementType allows field.
  • Character.orm.xml - Add updated_places, maps to Place updater field.
  • 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
  • Place.orm.xml - New, tracks name, type, description, updater, and updated time.
  • 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.
  • 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.
DataFixture Changes:
  • LoadBuildingData.php - Added BuiltIn logic for new settlement types, added following buildings: Warehouse, Apothecary, Guild Square, Guild District, Empty Moat, Filled Moat, Quarry
  • LoadFeatureData.php - Added new feature types, add logic for adding new ones
  • LoadSettlementData.php - Add in new settlement types
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.
  • Logic for Regional Lords to manage appointment of sub-lords.
  • Controller for Places? Or should we just build this into the existing Settlement Controller?
  • Update BuildingTypes with settlement type info.
  • Determine settlement types.
  • Update Doctrine config for building types to add type field.
  • Update Building DataFixture to load in new types.
  • Add separate logic for troops garrisoned other than cities/villages
  • Add conditions for construction of dockyards and filled moat.
  • Add resource data for new buildings.
  • Add logic for Sublords? Perhaps with individual translation strings depending on what type of settlement it is.

Pages: [1] 2 3 ... 104