Messages

1

Conduct & Design Discussion / Re: Burn ships!

« on: May 07, 2018, 11:37:57 AM »

This wouldn't be hard to do or implement, as far as stealing and burning ships.

Making rivers navigable would be.... tricky, due to how the game handles the land/sea logic, and how it handles you coming ashore. I'd like to do this, and I think it's sorta on my TODO list already, but it's nowhere near as easy.

A quick fix for the river thing would be to treat travel near a river the same as travel by road, e.g. you get a speed boost by following the course of a river but still aren't able to cross it unless it's at a bridge. This would allow effectively the same benefits as trying to work in a river-travel system but without the coding headaches, and having to place docks on rivers.

An alternate solution would be to edit the map, and make major rivers wider and just treat them the same as ocean spaces, and allow docks on adjoining provinces. That way, the code shouldn't need to be touched, the map would just need editing.

Also, there are lakes in the game which you can't cross. It would be nice if docks were allowed there, so sea travel could short-cut settlements on each side, would that just be a matter of editing some database settings for the adjoining settlements?

2

Conduct & Design Discussion / Re: M&F Changelog

« on: April 08, 2018, 03:29:11 PM »

If there are going to be "places" could you also include improved means of managing existing structures? e.g. removing unwanted roads and features would be a nice thing to have if the role of places external to the cities is going to be increased.

Also, i'd suggest that the updates should be generalized, e.g. towers and docks should become garrisonable / buildable locations that can have troops stationed there.

3

General Discussion / Re: A Discussion On The Value Of Characters

« on: April 06, 2018, 01:10:01 AM »

I think there's often a vision in game design that a problem can be solved by a big stick rather than a carrot - punish a player to encourage them to behave in certain ways, rather than offer them some incentive to behave in a certain way.

That's right. Richard Bartle, the creator of the original MUDs also talks about this as a common stumbling block when creating online games. Devs often believe they can dis-incentivize a behavior and that players therefore must switch to the "preferred" behavior. But they can easily switch to the behavior of playing a completely different game or activity. When trying to shift players from Choice A to Choice B, you should take into account the risk of Choice C, which represents "play something else".

I'd suggest things like giving characters a bonus to settlement production; a bonus in battle; and so on depending on their past actions - i.e. charcters actually have to do something to earn experience (in the form of players clicking options while playing them). They wouldn't gain experience just passively. That may mean that people who really focus on development of a few characters might then actually gain advantages over players who just spam large numbers of disposable characters.

I don't think if that would help tip the balance in this particular scenario. Consider a players with a 10-character account, they've trained up their core characters, then during a war, they bump up to a higher-tier account and spam additional commanders. They're still getting the benefit of the high-focus training on their core leaders, but that in no way dis-incentivizes them from spamming disposable grunts. This is not a criticism of the idea, but we need to think through real-life examples to see if the policy would actually affect behavior in the way that's claimed.

The thing is, there's a huge disconnected between how many troops an account can have in their settlements, vs how many troops you can effectively mobilize. It's this imbalance that creates the scenario in which massive character spam is a winning strategy in warfare. So while putting a dampener on character creation could slow this down, it's only hiding the exploit below an extra level of paperwork, not removing the core issue of game balance.

4

Off-topic Chat / Re: Helllo! newbie on the forum!

« on: February 26, 2018, 12:10:36 AM »

Hi People!
 
Not long joined up! I hope "<board name>" is ok to post in, saw a few posts by <frequent poster name> and thought i could contribute here
 
I tried to reply to <thread by frequent poster> but it popped up an error, is it because i'm new? (i assume it is lol)
 
I'm currently watching stranger things! > <spam payload link> < mine is ALL of em lol
 
Best Regards

5

General Discussion / Re: A Discussion On Allowing Non-Human First Ones

« on: February 23, 2018, 11:17:52 PM »

What I think would be cool is a dynamic system. Here's a rough idea:

Have ethnic groups, derived from realms / subrealms. You can pick one as your primary identity when you spawn you character, and the realm creator gets to specify a set of (optional) bonuses and penalties for the realm. Children would be able to inherit the primary ethnicity of either parent. Possibly, allow characters to change ethnicity based on other realm memberships available to them, and based on marriage, so you can marry someone to get a new ethnicity, giving another use for marriages.

Optionally, allow each ethnic group to get certain +/- values for e.g. living in certain terrains, or for raising / leading certain troop types. I'd split terrains into three groups, mountains/hills, forests/marsh, plains/scrub, and troop ability into three groups too, archers, cavalry and infantry. So you could e.g. get a +2 in hill/mountain production and +2 in archers, but you'd have to take -1 in everything else to get that, or you can have an ethnicity that's an all-rounder. e.g. a large realm like Ascalon would probably make "Ascalonian" have the generic settings, and players could choose just to identify as "Ascalonian", but sub-realm ethnicities would be more specialized based on what terrain and resources are available to them.

6

Conduct & Design Discussion / Re: How to Tutorial

« on: January 28, 2018, 12:25:07 PM »

*Spurred you to try things, btw. "Spurned" means to reject disdainfully. e.g. "she spurred his advances" and "she spurned his advances" mean two very different things.

7

Conduct & Design Discussion / Re: How to Tutorial

« on: January 04, 2018, 01:09:56 PM »

In the vein of having an achievement system be tutorial-esque, i would prefer it's kept at more of a low level than that. Players respond better to immediate small goals that chain together, rather than making a long-term goal such as "become a ruler".

I would code small tasks "create a character", "place a character in the world", "take a knight's offer", "control a settlement", "set permissions on a settlement" etc. things that show you've found your way around some aspect of the game's interface. new task would become active whenever you complete an old one (some would be coded that you need to complete a different objective before they're available).
 
the point of having achievements is that they keep the player logging back in, so they need to be responsive and achievable right from the start. if you look at any system with "levels", then the first few levels (and/or tasks) are always really quick to achieve, then things gradually slow down. Having only things like "won a battle" don't serve that gameplay purposes, because you need to be playing too long to achieve that.

So ... basic design principles from any "level up" and/or achievement / badge system (they're effectively the same thing from a player psychology point of view) is to make them incredibly easy to achieve at the start, then gradually make them cost more work to achieve. You can signal this by categorizing them as bronze, silver or gold achievements. Winning a battle would be a "gold" badge, which making a character only nets you one bronze badge.

Having only long term badges such as for winning a battle or becoming king serves no purpose. Nobody is going to log back in who wasn't going to anyway because there's a badge for becoming king. But ... if they have a list of immediate tasks that they're told they haven't finished, then many players will log back more often to get those.

It also helps if there are separate tracks with overlapping goals. So, you've achieved one goal, but your halfway to getting another unrelated one. This is acknowledged by Sid Meier in the sucess of the Civilization series. They have separate milestones each with their own timers (producing units, making building, building wonders, your next tech upgrade, exploring), so you're never "finished" everything at once: you're always in the middle of a number of task. So you always feel "well I'm only a few turns away from producing XYZ so I'll keep playing" but then you achieve that next goal, e.g. producing a new technology, and you realize that then you're only a few turns away from building the Pyramids, so yet again you keep playing. having lots of small, little goals along the way is what leads to player retention. Promises of a big reward right at the end do not.

The only thing to watch out for is that if people are motivated by small frequent achievements, then you never really want a situation where they've run out of things to aspire to. Have some really difficult ones in there. You'd be surprised: if the goals just run out, lots of people will stop playing. However, if there are e.g. three near-impossible goals they won't ever feel like they've "finished" the game. Also you can do things like having repeat achievements for achieve "X" of something. e.g. you get a badge for having one vassal (per account), but then have that badge update to be to have 3,6,10,15  vassals (not at once, but across your entire account's history).

you can get clever about the type of behavior you want to encourage. e.g. if you have dungeon-exploring badges, and make ones for exploring 1 dungeon then 3,6,10,15 etc (pascal's number), then you're going to get a subset of players who go off dungeoneering a lot, who wouldn't do that otherwise. Hell, even counters that keep track of how many times you've done some tasks are enough for many players. e.g. if you had a stats page showing how many battles you've won / lost, how many dungeons you've ever explored, etc, then players will gear their playstyle to increasing those numbers. You don't need to get technical here, just take advantage of how silly us humans are.

8

Conduct & Design Discussion / Re: How to Tutorial

« on: January 02, 2018, 02:42:30 PM »

Video tutorials are a pretty good idea, but keep them very short and specific, and have them cross-linked from within the manual, but also from the relevant page inside the game. So basically you have a troop-training video linked from both the manual, and from the troop-training screen, and have the video screen also have links to see all the topics covered. This set-up would add some interactivity and life to the game for new players.

however, building a decent in-game achievement system should definitely be on the list of goals.

in-game achievements are great for retention and getting people to log back in. They can also be used to foreshadow "things you can do" in the game, e.g. that gets around the problem of people not knowing what's possible. Additionally, if the "achievement builder" is built into the game itself, then it can be used by the devs to create missions, but also by players to create complex player-created missions.

I'd suggest that in-game tasks can be set as being at the character-level or the account-level (e.g. there should be an achievement for becoming a vassal to another player, but only once per account rather than per character, which would be silly: not every character should do every action), and they should be able to be chained together, with any new tasks that the current task opens up being shown in the current task (in a similar fashion to Civilization's "tech tree"). This would allow only a few tasks to be visible at the start, but gradually reveal new things you can do.

A basic flow of achievements would be "create a character", and then once you do that, several new ones appear, such as "become a vassal", "place a character in the world". In this case, taking a knight's offer right off the bat would clear off both of those tasks.

Once in the game,  there would be other achievements such marrying another character (only counting different accounts), and taking over a settlement. And once certain requirements are met, then that opens up new tasks. e.g. once you have a settlement, then that opens up certain game possibilities, and the way the task system opens up can mirror those possibilities, while also encouraging inter-player interactions such as making knights' offers. e.g. have a "make a knight's offer" reward, then a reward for having your first vassal (from a different account), but you could also have achievements for having e.g. 3 and then 5 vassals in total. Taking the vassals with your own account wouldn't count. While some people could "fake" that with multiple accounts, they're not actually gaining anything (just the abstract concept of having completed something), and most players wouldn't do that. It would incentivize enough extra knight's offer creation to really make a difference.

9

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 17, 2017, 01:24:52 AM »

I think it's enough burden already. Managing the characters is already a burden. Adding in the ETAs will make small player's time much more efficient since they tend to log in less often. Like I said, large players with lots of things going on won't actually benefit as much, in a proportional sense. It's not often that you have e.g. 20 character marching around doing stuff, you still need to log in to check town training and the like. And with 20+ characters all moving, just logging in per hour, and seeing who is no longer moving is efficient enough, since it's going to take time to order them to do new stuff anyway.

10

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 17, 2017, 01:11:03 AM »

It fails the "user pays" logic however, since it's more server burden if you need to open up many pages just to find out basic information. The user isn't in fact paying anything, they're just consuming more of the game's resources because the designers chose not to make it clear whether things are ready or not.

The game should ideally be designed to encourage players to efficiently use the game's resources then any restrictions be designed around that. Making it so it's costly in resources to the game if you have lots of characters, and that slows you down, is just a bad idea.

In fact, with more characters I could quickly log into the game, see who's stopped moving from the main screen, and find one that's idle to do some task with. With a large group of characters, individual ETAs don't actually matter so much, as you can just log in every hour or so, see who is free then get them doing stuff. Not knowing decent ETAs on e.g. travel, in fact disproportionately penalizes those with only a few active characters, since missing out on the exact ETA represents a bigger percentage of their total activity time. Efficiently queuing actions actually makes the most difference when you have very few characters, not more.

11

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 17, 2017, 12:27:21 AM »

Yeah, it's a good intention, however using "shitty interface" as the way to gate content leaves a lot to be desired, since making it hard to know when things are happening also hurts new players with only a few characters from getting precise information about when they can do stuff. If they did get just the ETA on actions on the main page, then it cuts through all the specialized knowledge you need to gain to work that out.

It also begs the question, if they're offering a 50-character mega account for more money, but the game actively conspires to make playing that suck as much as possible, from a user-interface point of view, why that option even exists.

Personally, I also think that smaller character limits would be a good thing. With less characters, people will be more invested in each character, and things like cross-account marriages will be more appealing.

thinking about it, one system that could work is to switch completely to town slots instead of character slots. e.g. 12 town slots for a free account. However, you need to allocate at least three town slots to each character you create (to avoid the potential problem of not being able to take a town with a new knight). This would mean a free account could make between 1-4 characters, with up to 12 towns between them. Sure, most people could continue to play as before, but you wouldn't be forced to create all 4 of your theoretical characters just to get your 12 towns. A possible extension of that would be to make it so each additional character costs one extra town slot than they can control. e.g. make it so a single-character free account gets 15 slots, but each additional character you make gets three town slots, but costs 4 slots. So you get some material benefit for making a few less characters. Then, the paid tiers can be based on this concept scaled up.

12

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 16, 2017, 11:46:31 PM »

sure, the information is there, but it's not convenient to have to do a subtraction, for the server time hours, to work out how long it's going to take, then to add that to your local time, just to work out when something is going to happen. If you want it accurate, then you have to handle things like carrying over minutes and hours too, for both legs of the equation, so it's more than just a subtraction and an addition: that can get complex:

- subtract the server minutes from the target minutes, and handle the wrap-around / carry in case it goes below 0 minutes (e.g. add 60, and carry the 1).
- next, subtract the server hour from the target hour, add in the carry bit. Now, you have the ETA in hours and minutes. Yay.
- now, to get the local time to completion, add the ETA minutes to local minutes, and if it overflows 60 minutes, subtract 60 from it, then add 1 to hours
- now, add ETA hours to local hours, and it if overflows 24 hours, subtract 24, and add one to the day

Worst-case scenario there is that you needed to do 11 additions/subtractions, just to get the ETA in local time! It's just being silly not to provide the information in an accessible manner.

In fact, it would be nice if on the main character page it shows an actual ETA next to each character with a queued action, e.g. see a countdown next to each mention of travel, annex, battle etc. Basically it's a waste of time to force people to open up each and every character they have and navigate through multiple pages just to see "ah, <thing> isn't finished yet". Common sense would suggest it would be better to give an estimate of completion for each character's current action on the main character screen.

Some people do in fact have slow as fuck connections, which are charged per the megabyte. If I can play a game that doesn't force me to open up multiple pages just to find out that nothing has actually happened yet, I save both time and money. Make the available information on all ETAs more conveniently located on the main character page then all of the problems mentioned basically go away, such as new players not knowing how the day cycle works: you can see how long until each character arrives where they are going, without needing to open up each one, then only access the characters for whom you can actually set up interesting things.

Right now, if I'm not in the game, i just know several characters are "travel"ing and have no real information about when they're going to arrive and I should come back to the game to get stuff done. Unless I wrote the "days travel" amount down for every character when I set travel, no other information about when they're going to arrive appears unless i open up each and every character to check. That's just a gap in the design, it serves no benefit to the game by being obtuse.

13

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 16, 2017, 10:54:45 PM »

Well I got that working, plus I added in a dynamic countdown as suggested, and then animated the progress bar too, because wth. Here's a standalone script that should do it. Features:

- currently works on http://mightandfealty.com/en/queue/ page only. Can add support for other pages if needed later.
- replaces server ETA with local timezone ETA, should use your browsers settings
- adds a countdown
- updates the percentage progress bar every second, plus shows percentages to two decimal places (it's an estimate only, just to make it clear that the value is being updated)

Code: [Select]

// ==UserScript==
// @name     Might And Fealty - Local Timezone
// @version  1
// @grant    none
// @include  *mightandfealty.com*
// ==/UserScript==

var counters = [];
if(window.location.href.indexOf("/queue/") >= 0)
{
  var q1 = document.querySelectorAll("td.progress_column + td");
  var q2 = document.querySelectorAll("div.progressbar .progress_value");
  for(i = 0; i < q1.length; ++i)
  {
    var k = q2[i].innerHTML.replace(/ \%/,'');
    var ct = new Date();
    counters.push({ 'time' : q1[i].innerHTML, 'percent' : k, 'loadtime' : ct });
  }

  updateCounters();
}

function updateCounters()
{
  var q1 = document.querySelectorAll("td.progress_column + td"); 
  var q2 = document.querySelectorAll("div.progressbar");
  for(i = 0; i < q1.length; ++i)
  {
    var date = new Date(counters[i].time);   
    var options = { weekday: 'short', day: 'numeric', month: 'short', year: 'numeric', hour12: false};
    var diff = (date - new Date())/1000; // seconds
    var sec = parseInt(diff % 60);
    var min =parseInt(diff/60)%60;
    var hr = parseInt(diff/3600);
   
    var time_fraction = (new Date() - counters[i].loadtime)/(date - counters[i].loadtime);   
    var percent_update = parseInt(counters[i].percent) + (100 - counters[i].percent) * time_fraction;
   
    q2[i].childNodes[0].innerHTML = percent_update.toFixed(2) + " %";
    q2[i].childNodes[1].style.width = percent_update.toFixed(2) + "%";
   
    q1[i].innerHTML = date.toLocaleTimeString("en-US",options) + ": <span style='color:purple'>" + ((hr<10)?"0":"") +  hr + ":" + ((min<10)?"0":"") + min + ":" + ((sec<10)?"0":"") + sec + "</span>";
  }
 
  setTimeout(updateCounters, 1000);
}

As for the other script, I will get around to updating it sometime, however as a quick fix for the old script, search for the value 200 where it appears, and replace with something arbitrarily high for now.

14

Conduct & Design Discussion / Re: Convenience tweak for players from different timezones

« on: December 16, 2017, 06:16:20 PM »

I think it's a little more of an issue than that.

Currently, I have a completion time on one event of "Sat, 16 Dec 2017 23:05:00 -0600"

Where I am now, the local time is 4:27 AM on Sunday.

How to convert one to the other isn't intuitive, and even if I get a formula for doing so, I'd have to take into account that both my location and the server location have entirely incompatible daylight savings rules, so there could be up to 4 different time offsets depending on the time of the year, and even with a formula, it's possible to make a mistake now and then, and having to recalibrate it manually every time is just a waste of effort, when you only want to quickly know when something is finishing. Also, there's the fact that this is going to trip up just about every new player with an unnecessary obstacle to getting information they should have easily available. With a game with new player recruiting issues there's no excuse for leaving annoying things in the UI that can easily be fixed.

Another related issue is that the game mixes up ETAs in server time and game-specific time. e.g. when I first started playing, I set travel, it said "X days" to get to the next town, and I thought "geez that's slow!" And I'm not the only one. I'm pretty sure that quite a few of the knights who sign up then never log in again have been fooled by the ETA system into thinking it's going to take e.g. 2 actually real-time days to get to the nearest town, rather than 12 hours. Or if they start training and see "15 days" to train some basic troops, they're likely to think that's 15 actual days, not < 4 days. Such a sense of "slowness" might be turning a number of new players off right at the start. It would perhaps be better if the game signaled how long ETAs were in both game-time and real-time so that new players can know when to log in to continue. All the little things that turn new players off add up to a game that is counter-intuitive about things that should be immediately clear.

There are effectively two* different ETA systems, and they are ingeniously designed such that neither of them tells you how long something is actually going to take without applying a bunch of arcane math formulas that you need to memorize. Both of them display a mastery of user-interface design thinking: if the term "days" is ambiguous to new players then how do we expect that new players are going to stick around long enough to realize "oh, when it says 'days' it means '6 hours' ". That's not "good design" or "flavor" - it's just shitty design.

* in fact, the weapon production system showing as per-week rather than per-day effectively makes that a third ETA system, which is also incompatible with the other two types. Rather than per-week it would be much better to display produced weapons per-day, but have two decimal places. It will both be more accurate and easier to use: you could multiply amount produced by days remaining, to work out how many items will be finished by the time training ends without needing to add a conversion factor for weeks to days every time. Weeks being 36 hours are entirely irrelevant to anything else, they should be removed from relevance from the few remaining places they pop up, because it's not a good design decision to even have them.

15

Conduct & Design Discussion / Re: How to Tutorial

« on: December 06, 2017, 02:53:15 AM »

All you said was "give the tutorial a skip button". That's not really addressing my suggestion at all, so how can I go into depth about that?

Tutorials, especially standalone ones that are flagged as such - they suck. All good designers say that you shouldn't do this. You teach through doing, every design guide says to do that.

Phrasing the learning as achievements lampshades the fact that it's a tutorial system. People are collecting badges instead of "completing tutorial objectives". And if it's an achievement system you're free to pick and choose the order you try the things, and people can voluntarily skip parts of it, but come back later and complete them later if they feel like it.

Also, it allows you to structure things in the achievement system to support your broader goals for the game, e.g. a "become a vassal" achievement will ensure that most new players will take at least one knight's offer instead of just dropping into the game wanting to be a lord straight away. And chain one on that where you have three of your characters being vassals, you get another badge. Plus you can make badges for creating your first knight's offer, having 1 vassal, having 3 vassals and so on. You can thus incentivize the behaviors you think players aren't conducting enough.

The thing is, the systems you need to build for this are less complex than what you'd need to build to create a special "tutorial world" and make sure it's got a unique slice that resets for each player that is doing the tutorial at the same time (thus needing many copies of the tutorial world - one for each player who hasn't completed the tutorial). Also, many of the game actions have a time component, e.g. travel, troop production etc. It's just not suited to having separate world(s) for the tutorial. How long are things like travel and troop training going to take in the tutorial? If it is regular speed, then you're forcing players to spend significant time outside the game if they want to see the tutorial content, and if it's accelerated, then they might get the shits once they get into the game proper and it's slow. either way, it's not going to be good for retention.