Can’t quote myself from the restricted-access Lounge thread, so pasting here instead:
PvP matchmaking is impossible to evaluate on its merits in the testing environment we’re in. I can’t tell you anything about how good the algorithms are (or if indeed they’re any different) as it’s almost entirely dummy accounts we’re up against; and by now we are (well, I am) so far ahead of the test accounts in power that there’s really no challenge to any of them.
That being said, matchmaking is a server-side process and I wouldn’t expect it to change with a client-side update like this.
If that’s the case, then why wouldn’t they just use the code from the console servers instead of applying this kludge of a ‘quick fix’? (Really not a coder, here - it’s an honest question). I don’t understand how the Unity client will interact with the servers - I assume they’ll need to update the code on the server side to interact with the new client?
I don’t know how their code is written, and I can’t see the traffic between a console and their service anyway, so I’m spitballing here.
Typically, you create a web service with an API, which is often (but not always) HTTP-based. In the case of matchmaking, your client would call the web service endpoint, something like: “http://gemsofwar.com/api/find-opponents”, and pass in authentication data in the header corresponding to your session token or authorization data. The service would respond with an HTTP response, the payload consisting of offerings, and other metadata for use in client display (relevant here would be team score). Changing the client would not necessarily require changes to the service, though if new features are exposed then the service would need to be augmented to supplement those.
What I don’t know is whether the services in use by Console and PC/Mobile are the same. Clearly, the environment (sandbox, or group of players and economy) is different, but there are two possibilities as to how this is accomplished:
There is a single web service, which is able to provide data for and perform operations on behalf of multiple sandboxes.
There are separate web services supporting the PC/Mobile clients and the Console clients; potentially even two separate web services for the two consoles.
If it were me, and I were developing all clients from the ground up, you can bet I’d invest once in one web service and make it smart about respecting sandbox (1). But in the case of Gems of War, the Console version was developed by a separate team from the PC/Mobile one, and could quite conceivably have a completely separate service supporting it (2).
If (2) is the case, then the development team has a decision to make at the point of the Unity switchover: do we also move to the Console service, and migrate the user data to that service, or do we stick with what we’ve got and maintain the existing API? My money is on them not juggling too many balls at once, and changing over the client only in this instance.
Thanks - I think that helps me understand better. So, short answer to my implied question is: switching to Unity might not result in any change to the underlying matchmaking mechanism for PC/Mobile players. Whatever the slow fix is might or might not be related to or timed with the 3.05 update.
shouldn’t whatever bugs, matchmaking calculation errors fixed by now? we have been arguing for so long. i do remember they say a very long time ago that defense team does not affect your pvp choices and several people prove them wrong at the time. why the fault rest on the players? should low level players be at fault for having low score?
edit: i didn’t meant to reply to you. sorry accidental reply button.
I don’t agree that it is an exploit in the same way. People have come up with a very fast team that is steam-rolling the opposition. That is different than people setting up defence teams that allow themselves to be steam-rolled for mutual benefit.
Killing one of your own troops on the 1st turn is the entire purpose of Elspeth. She is doing exactly what she was designed to do.
Having Elspeth fail to summon (ending the match) when she is the only troop and casts on herself was a bug that has apparently been fixed in the Unity update, so that was unquestionably an exploit.
I’m not saying that there isn’t a design/balance issue to deal with, but I don’t think it is an exploit.
There are a number of troops with the ability to “sacrifice”. If doing it on the first turn is an exploit, then what turn would be “acceptable” and not an exploit? 2nd?, 7th?, 13th?, 34th?
No it is not, sacrificing troops has long been an intended part of the game.
One troop defense to lower invade team difficulty has never been intended.
…
Listen, you got your point across several hundred posts ago in this thread, even stubborn souls like me came to see your point of view and had to agree the way the fix was implemented was bad.
This weird comparison now is just folly… nothing good will come from it, let it be.
Let this issue die and let’s together come up with ideas for more reasonable ways in the future to avoid having to face annoying meta teams all day long.
For some of us, there aren’t any options. We were dumb enough to give the devs hundreds of dollars so now we can’t build “weak” teams.
Furthermore, deliberately building weak teams, whether they’re 1 Elspeth or 4 Ogryns, still goes against every justification the devs gave us for fixing the Elspeth thing.
I’m asking them to stop being selective and start being consistent. That’s not too big of an ask, IMO.
Managing the economy is the devs problem. But if they were concerned about people playing too fast, they probably wouldn’t introduce the ludicrous speed setting, which they apparently are in the next update. We’ll see if we get the full 4x on Monday or if that was just for the beta testers.
When that team was first publicized on the forums, I read and bookmarked the thread. I haven’t tried it myself, but it has been in the public domain for a while now. A bunch of people who said they tried it thought it was high-risk, high-reward and wasn’t reliable enough. Maybe it has been improved on now, I don’t know. It might have taken a while for it to spread and propagate. In any case, if it is a serious problem from the devs perspective, then it is up to them to do something about it.
accidental reply button.