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 - Cipheron

Pages: [1] 2 3 ... 14
Off-topic Chat / Re: Helllo! newbie on the forum!
« on: Today at 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

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.

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.

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.

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.

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.

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.

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.

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 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 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  **
// ==/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 });


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.

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.

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.

Conduct & Design Discussion / Re: How to Tutorial
« on: December 06, 2017, 02:27:07 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. And if you're clever about what those slots relate to, then you can give the players an extra push to achieve the meta-goals you have for what you want players to be doing, without forcing them to do it.

Also, standalone tutorials are heavily frowned upon in game design, the idea is almost completely outdated - it's much better to integrate your tutorial into the game itself, but in an ongoing way. Basically, instead of having people do some out-of-game tutorial, you have a small number of achievements visible to start with, and completing each one opens up related ones, e.g. you have "pathways" that the player can explore that go into more and more detail for a specific type of activity or play style. Hell, to build a tutorial system you'd really need to build all these systems anyway, it would just be easier and simpler and have more benefits to build it into the game as an "achievement system" which players love rather than calling it a "tutorial" which is basically groan-worthy to most players. It's about psychology here: the exact same system phrased in a different way can be perceived in a different way.

Conduct & Design Discussion / Re: How to Tutorial
« on: December 05, 2017, 10:47:05 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.

Conduct & Design Discussion / Re: How to Tutorial
« on: December 02, 2017, 05:30:14 AM »
Well, another way to soft-code a tutorial is through and achievement system. e.g. you make a bunch of achievements, give them some nice appealing graphic, and when clicking on the info-tip for the achievement it links you to the relevant section of the manual or wiki. The advantage is that achievements are entirely optional and can be achieve sooner or later, but they are very appealing for a wide range of player types, and don't give the same groan factor of having to do a tutorial.

Pages: [1] 2 3 ... 14