ClonesGame.com Forums

[Simon]

Nice, this looks fine in the video.

You might consider displaying the open cursor (square) only when the cursor is on top of an own clone, and display the regular cursor (arrow) otherwise. This is solely for familarity, and not a great deal.

I will probably use this method of assignment in the future. The precision of selecting one particular clone when clicking on the bunch isn't necessary: There is directional select, and clones don't have permanent skills. It's merely important to have good assignment priority -- select workers over walkers, but walkers over workers when the workers are performing the same skill that is to be assigned. I believe the game does this already.

You might consider to invert the priority while right mouse button is held. ;-)

-- Simon

[rt]

It'll never make it worse to add an additional option that players can choose to ignore if they prefer the default scheme.

I didn't say it would make the game worse, i said it would make the player worse. The game was designed to select a clone first, then issue a morph. Playing it any other way will put the player at a disadvantage and reduce functionality in comparison to the default. Although maybe some of the benefits you mentioned will offset this a bit. I've lost matches to you in the past, and i've no doubt i will lose to you in the future but it will be interesting to see if these matches feel any different with you using the new (old?) scheme.

The directional queue could trigger when directional select is used but only clones walking into the other direction are under the cursor. It's a bit limiting if you got a bunch of clones

I don't understand, if you have LEFT select on and you click on to a bunch of right facing clones then wouldn't you expect no clone to be selected/morphed? It sounds like you are suggesting that the click should left-queue the morph to the right facing clones?
In testing the scheme the directional select works great, but directional morph cannot be used. Although the new Transition Queue can replace it because a direction change counts as a transition, so this might be a non-issue.

With temporal queue, you mean assigning while a clone is in the air, or something else?

The Temporal Queue (future clone) is activated by selecting a clone and then pressing Y to see the future of that clone. If you issue a morph now the clone will do it in the future. Not sure if this would work under the new scheme, but it's not a deal-breaker. Although it can help to plan ahead and space out morphs, also it gives you more precision on a lag connection since the future clone is locally predicted forward.

[rt]

You might consider displaying the open cursor (square) only when the cursor is on top of an own clone, and display the regular cursor (arrow) otherwise

Currently we use the square cursor to indicate that a click will issue a morph, either under the new scheme or for the "spam" mode. If we displayed the normal cursor we might need some other way to indicate which mode you are in.

I will probably use this method of assignment in the future. The precision of selecting one particular clone when clicking on the bunch isn't necessary

It depends how precise you want to be.

clones don't have permanent skills. It's merely important to have good assignment priority -- select workers over walkers, but walkers over workers when the workers are performing the same skill that is to be assigned.

Yes this will be important, i think it's ok, but you'd have to play it and provide feedback. One question though, with the directional select should it turn off after a morph is given, or remain on if triggered by the wheelmouse?

[geoo]

It'll never make it worse to add an additional option that players can choose to ignore if they prefer the default scheme.

I didn't say it would make the game worse, i said it would make the player worse. The game was designed to select a clone first, then issue a morph. Playing it any other way will put the player at a disadvantage and reduce functionality in comparison to the default. Although maybe some of the benefits you mentioned will offset this a bit. I've lost matches to you in the past, and i've no doubt i will lose to you in the future but it will be interesting to see if these matches feel any different with you using the new (old?) scheme.

You're still not really trying to understand my post, are you? What I said is totally independent on which control scheme is superior (which we agree to disagree on), because it is simply a logical statement. Let me lay it out for you (please read carefully ): Having the option (as opposed to picking the option) will never make the player play worse, because any sane player will choose the option that works best with him. And for any player, the (subjective) better choice of the two will work no worse than any fixed one of the two.
In other words: max(A, B) >= A, where A is the clones selection scheme, B the lemmings selection scheme (or to be more exact the quality of play for a player if he chooses that control scheme). You're not gonna deny that mathematical truth, are you?
That's why my first question ("what's the disadvantage of allowing it as an option?") was rhetorical (and not at all related to which is the actual better option which you understood it to be), because having this option (as opposed to picking that option) can never be detrimental to the game or the player.

I don't understand, if you have LEFT select on and you click on to a bunch of right facing clones then wouldn't you expect no clone to be selected/morphed? It sounds like you are suggesting that the click should left-queue the morph to the right facing clones?
In testing the scheme the directional select works great, but directional morph cannot be used. Although the new Transition Queue can replace it because a direction change counts as a transition, so this might be a non-issue.

Ah, then if the transition queue can handle situations like this anyway, then I guess the directional queue can be ignored for this mode.
I've never used the temporal queue, so I reckon at least I won't miss it.

On that matter, I was wondering, is it possible to assign the same key to different functionality in SP and MP? For instance, I need Freeze Time in SP, but that key is unoccupied in MP because Freeze Time is unused there, so would it be possible to assign it a different functionality (e.g. transition queue) to it in MP, without resetting it each time I switch between SP and MP? Would be kinda handy, otherwise I'll have to find some other key for the TP.

[rt]

Having the option (as opposed to picking the option) will never make the player play worse, because any sane player will choose the option that works best with him.

We seem to be going in circles here I never said that having the option would make the player play worse, i said that using the option would. It's obvious that having an additional option won't affect a players unless he uses it (other than GUI complexity), so it doesn't make sense to debate having an option without discussing the impact of it's use. Perhaps it should be a multiplayer-only option?

On that matter, I was wondering, is it possible to assign the same key to different functionality in SP and MP? For instance, I need Freeze Time in SP, but that key is

I've never tried this, but you could test using the 2nd keybind slot for an action, it may not auto-erase the key from another action's 1st slot. It would be nice to do what you mention, since there are a lot of hotkeys to manage.

[geoo]

I never said that having the option would make the player play worse, i said that using the option would.

Well........
You always quoted my posts about having the option to start what turns out to be talking about using the option without explicitly saying so, so it always seemed like you were talking about having the options. (You once even explicitely said "The disadvantage of allowing it as an option is implied from the disadvantages of the scheme: it will make you less effective as a competitive player." - allowing as an option here, not selecting as an option) That sure is a confusing thing to do. Please stop confusing me like that and only quote what you're really referring to next time.
When I rhetorically asked "what's the disadvantage of allowing it as an option?", I wasn't out to ask for a lengthy discussion on the disasvantages of the scheme, but wanted to point out that there's no harm in implementing the option, to support that it gets implemented.

I've never tried this, but you could test using the 2nd keybind slot for an action, it may not auto-erase the key from another action's 1st slot. It would be nice to do what you mention, since there are a lot of hotkeys to manage.

Nope, doesn't seem to work. I have some keys double assigned ironically, but I don't remember how it happened, might have been that it just happened when new features were introduced whose default keys coincided with some keys I had previously assigned to different functions, and I never bothered to change the bindings of the new feature.

Btw, I can't seem to discard changes I did to the key bindings, there's only an Okay button, no Cancel button.

[rt]

Btw, I can't seem to discard changes I did to the key bindings, there's only an Okay button, no Cancel button.

This by design, there is also no "undo" or "cancel" on the Options screen, but you can reset to defaults. We should probably add a cancel button though.