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 - De-Legro

Pages: [1] 2 3 ... 164
1
So, not something you'd be interested in seeing then?


Not personally, but experience should tell that I am not a great candidate for determining what the majority might like.

2

On a different note, De-Legro, if you do the time swap in javascript, you can have it grab the user's timezone info from the local machine rather than have to figure it out server side. Nothing says we couldn't grab that through registration though, much how forums do these days. If there's an easy way to have it convert to local time before page generation, having a method for it wouldn't be bad as we'd not need to duplicate code elsewhere, though we could do that in Javascript through the twig implementation.



Yup I noted that advantage.


There are ways however of extracting the time offset from the client and sending that back to the server, for example this explains a way to do it using cookies


http://prideparrot.com/blog/archive/2011/9/how_to_display_dates_and_times_in_clients_timezone


If we had reasons/advantages to knowing this data at the server that would be ideal.




I should note that if we want to use real time ETA updates though, you would want to encapsulate at least some of that in javascript, as it makes no sense to tie up a websocket or a make frequent ajax request just to update a clock.


I've been looking for ways to encourage people to subscribe, and making it so subscribers can see the hours, or minutes even, remaining on these things might not be a bad idea. It doesn't restrict information from free players, but rewards subscribers.

This reminds me of the Travian/Tribal War style games and how they would unlock a much better interface with proper management pages if you paid a monthly fee. Don't know how other people feel about such things but it pissed me off enough that I never purchased anything from those style games.

3
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.


As someone that has played large amounts of characters, in excess of 100 in the past, I can tell you that such a change would have massively cut down the burden of those characters, probably increasing my efficiency by 50%. That would have allowed me to increase my character count by 50%, I don't think that is something we really want.

4
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 game should ideally be designed to use the absolute minimum of 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. It's slow to do things with 4 characters: the slowness just scales linearly, it isn't more costly per character for having more characters, so it fails the test.

In fact, with more characters I could quickly log into e.g. 15 characters, see what each is doing and find one that's idle to do some task with. Compare that to having just 4 characters, logging into all of them to check if any have arrived at their destinations. A guy with e.g. 20 characters moving can just log in every hour, see who stopped moving then do stuff with them. Those aren't the people benefiting so much from detailed ETAs, because they are more or less guaranteed to have some dude who stopped moving in any time period. It's people with smaller numbers of characters who would benefit most from knowing reliable ETAs for their characters, since they wouldn't have to log in as often, only to find out nobody is actually ready to do stuff.


The server burden of serving pages is minimal, bandwidth is not an issue. Memory and CPU utilisation on running turns is far greater. Yet it doesn't fail user pays, more characters = more pages served and you are charged more for the privilege. You can argue for "best practise" all you want. Best practice takes resources, initially in order to design and implement systems that achieve the stated design goals while maintaining best practice. And now resources to replace what exists and still implement other required systems. Those resources have and continue to be lacking.


So again while I agree that having ETA's on the character page would be handy, what are we implementing in order to retain character burden?

5
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. e.g. thinking about it, one system that could work for free accounts is - 12 town limit, no character limit, but you must have 3 free town slots to create a new character. Then, you can choose to either spawn one character, who can take up to 12 towns, or 4 characters with 3 towns each, or somewhere in the middle. This would avoid character-spam just to get your allocation of towns, but you'd still be free to do so if you really wanted.


Tom was quite clear on his logic regarding accounts. Originally I should note that the top tier had no character limit at all. Tom didn't want to restrict people if lots and lots of characters is what they wanted to do. Yet he recognized the potential power imbalance that creates and so run the concept of increasing the "burden" on a player if they decide to have large numbers of characters. The cost factor plays into that too, but mostly that was along the lines of user pays logic, you are consuming more of the game resources, so you pay more.


It may indeed be a shitty way, but it is effective and relatively cheap in terms of implementation time, ideal for a ambitious project that never had full time attention from its creator. To remove it would require the addition of other systems to achieve the same goal, and as we all know Tom rarely had much time to make such new systems, there was plenty that did and still does need fixing with existing systems.


So yes while it would be relatively simple to provide ETA's along with the event info on the character page, it needs to be done within the context of competing needs, assuming we still wish to follow Tom's idea of making more characters a larger burden on the player.

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


Well it did, in Tom logic. Toms logic was always to make things harder the more characters you had. A prime part of that was forcing you to log into characters to get updates on them. Having a lot of information posted on the character page makes playing 50 or more characters much much simpler. That is why he only ever displayed what he considered the most important statuses, battle, travel etc.


As to if that is still a design consideration, I don't know I haven't talked to Andrew about it. My preference has simply been to reduce the total number of characters that you can play at a maximum so that issues of scale become less relevant.

7
Alternatively the game could instantly tell you how many hours till completion remains.


Yes it could, I have no issue with that. We could always divide a day into six intervals and provide info in that if people want something IG rather than hours. I am not arguing against that, just pointing out that time zones etc are irrelevant to determining the ETA's based on the information currently given.

8
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.


Why would you do all that?Note estimation time, look at bottom of page for server time. From that you have how many hours till completion, apply that to whatever the local time is. The bigger issue for me is definitely the mixing of RL Time and IG Time. The main problem is in game time has no real resolution greater then a day. So while you can easily say something will take x.x IG days to complete, you can't easily say "Will Complete at Day XX.X Year YY, it just seems a bit clunky.


I am open for suggestions on breaking it down though so we have something we can use throughout the game. The issue then would be people will complain about how hard it is to convert IG time to RL time. So we need a good way to display the RL equivalent without ruining the immersion that trying to be consistently expressed in IG time gives.


As for the IG Weeks/Days, I would suggest that perhaps that long things like troops training and building should be expressed in weeks not just days.


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.


Demivar and I spoke about this earlier. It is completely possible to have the server deliver the correct time to the browser so long as people are willing to set their time zones. It is mostly a personal preference but I prefer to have this stuff done before the page is rendered rather then use javascript.

9
Conduct & Design Discussion / Re: Troops V2.0 - Unit Types
« on: December 11, 2017, 11:10:33 PM »
I think we need a better explanation of how you envision this new system. Because I am completely confused right now.
Do you just mean that mobilising troops from settlement garrisons will not be an instant action (as it is now) but a lengthy and costly process?

As soldiers are individuals you always have the option of moving/retraining them between forces. There would be some sort of retraining time associated.

With regards to mobilising units designated as militia, there is no current plan. I want to try and balance the ability to mobilise your militia in order to defend your neighbors, with the desire to put in some limitations regarding the ability of realms like Hawks to mobilise ridiculous numbers of troops when they go on the offensive. There is certainly a lot of balancing work to be done before this part of the troops upgrade sees the light of day.

10
Conduct & Design Discussion / Re: Burn ships!
« on: December 11, 2017, 09:42:41 PM »
Being an island realm is already a somewhat one-sided option, you know. Don't see anyone complaining. When you're raiding an island, you're already fucked if they manage to block the boats. Attacking mainland settlements leaves you a lot of room for manoeuvre. If your boats are blocked you can continue damaging the victim and then just leave by land eventually. If you're worried about unfair advantages, my suggestion does not create any but perhaps helps mitigate some.

Firstly lots of people complain, the "invincible" nature of the islands combined with the abundance of fishing settlements is the number 1 gripe I hear. That said if it is already one-sided, why would we want to introduce options that increases that advantage?

11
Conduct & Design Discussion / Re: Burn ships!
« on: December 11, 2017, 02:03:25 AM »
Yes let me burn ships. As a Island nation I can then force anyone that dares land on my island to remain their forever or die. Or you know I could just camp the ships and use block area to achieve the same thing.

The question is, what would the down side to burning ships be? Without some sort of consequence it would be a very one-sides option, particularly as I noted for islands.

12
Conduct & Design Discussion / Re: Troops V2.0 - Unit Types
« on: December 11, 2017, 02:01:25 AM »
What is unique about M&F and what I really like about this game is persistent mortal characters who, once trained, hang around until dead or disbanded and can fill any role you need. They can ride to battle or man the walls. Every soldier has unique history. This is fantastic.


What is suggested here I see as a serious downgrade. When we go for restrictive troop types, we go back from truly flexible individual soldiers to gamey "units/unit types". I see a lot of harm in this but I fail to see any real benefits. The announced benefit was that less active players would have an easier time building up their garrisons? Not important enough for such a huge change, imo.


I do like the idea to sophisticate the equipment supply though. I don't fully understand how it's supposed to work though.

When did I say I was removing the individual nature of troops? Professional or Militia they would retain the current system of being named and having history. It would also be completely possible to train militia troops into a professional force, or retire professional troops into militia. It would simply take time instead of the instant actions we have now. Nor did I announce anything about allowing less active players an easier time to build up garrisons.

As I said at the beginning this is not about adding more flexibility, but about presenting choices. Once troops actually have on going costs Lords will need to decide if they want to dedicate their limited resources into have more of the flexible professional troops, or having a larger over all defense force by recruiting cheaper militia forces.

13
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: December 06, 2017, 03:07:06 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 volutarily skip parts of it, but complete it later if they feel like it.

So long as people reailse from the start that the achievements are indeed structured to be a tutorial, then what you have is

wait for it....a tutorial, simply not a scripted one.

The reason a scripted tutorial is worthwhile for something like M&F is because there are facets of the game that you can't rely on being readily accessible. Things like teaching people how to mobilise troops, how to spot people using watch towers, starting battles, joining battles, settlement defense. These are all things that require specific circumstances, ones that quite possibly people don't encounter for months. Yet if you wish to teach and more importantly showcase everything that M&F encompasses, you need a way to unlock all those parts in a timely manner.

The entire point of tutorials is that you ARE doing, either through a scripted system or otherwise. If it wasn't doing, it would simply be a walk through or digitised manual. The tutorials I personally find most useful are those that are broken down into different topics and lessons. Allowing me to go to the ones I think I need, and also to return to things later when I find I didn't intuitively know as much about a system as I thought I did. So sure we could add "achievements" on top of a properly functioning tutorial system in the manner you prescribe, but that in no way addresses the issues of giving people the opportunity to pursue those achievements in a time frame that doesn't require significant dedication.

14
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: December 06, 2017, 02:49:19 AM »
I think you're focusing on the least important part of the suggestion here. Having colorful icons and stuff is a "nice to have" thing because it makes systems more appealing to use, however that's not the actual suggestion itself.

A "nice appealing graphic" was all I actually said in the actual suggestion. No more detail than that, so critiquing that on hypothetical details that I never actually said while ignoring all the relevant parts of the suggestion isn't really helpful.

An "appealing graphic" could be as simple as a simple shield outline, but with well-chosen color fills dependent on the type of achievement and a gradient / metallic finish. It doesn't have to be something you pay for, because that's nothing to do with what I was talking about. it's just good graphical design sense and understanding how color theory works, along with basic psychology. You make a bunch of colored basic shields you can collect for achieving different types of things and people will strive to collect them no matter how pointless it is. People don't care that it's pointless, they see slots that can be filled, they will want to fill them. You can utilize this to get players to achieve some of the goals you have for the game if you're clever.

No actually my focus was on why this system would be superior to a completely skippable tutorial in terms of actually producing system the eases people into the game. Graphics was a throw away comment at the end of my actual point. Since you only replied regarding graphics, I followed the thread of the conversation as it was.

15
Conduct & Design Discussion / Re: The 1.1 Update Topic
« on: December 05, 2017, 10:55:42 PM »
By graphics I was just thinking of nice icons and stuff, not actual pictoral things. Generally, the idea was just to make it appealing, it doesn't need to be expensive.

I fail to see the difference. Icon creation, at least good icons is still the domain of artist. Unless we could find a set of matching icons that would suit the task in the free domain we would still need to pay someone to make them, or find someone willing to donate their time to create them. Given that currently Andrew is already putting his own money into advertising and simply keeping the server up and running just where is that extra money supposed to come from?

For reference when I paid a UI artist to create a set of 10 icons in SVG format for a game prototype I was working on, it cost me $700 AUD.

Pages: [1] 2 3 ... 164