Limit of different skills: currently 12.

With any redesign to fit more buttons on the panel, this limit becomes oddly arbitrary. It has come only from the UI restrictions. Since 14/15 isn't much more than 12, I'd love to get rid of this limit.

One alternative is to keep only 12 buttons, and sort, producing such abbreviated gaps. That's already much better than unsorted panel. But it would maintain the strange number of 12 buttons for 14/15 skills.

Enforce ordering without gaps: That's the first thing I tried, and I have working code that does that. Then I felt the problem to be in the strange number of skill panels.

ccx:

Hunch about too much space allocated to non-skill buttons: Thanks, interesting feedback. I'd have imagined them more important.

Future-proofing: These days, I'm actively discouraging ideas for new skills. Looking back at the past 5 years, I have regrets about having implemented the runner, despite people liking it. The batter is a must-have. The runner only makes sabotage better, which is strong enough without. Should the game ever get more skills, which I consider unlikely in the next 3-5 years, then another UI change is in order. And people would then have to live with 20 skills allowed at the same time, or re-impose a limit of skills per level, then fix existing levels.

New skills would increase the burden on new players. For experienced players, the single-hand hotkey layout is already full, and can't take additional unique keys well at all. You don't want to put distinct skills on the same hotkey. If you put similar skills on the same key, then they're probably similar enough to cull one from the overall design.

If I got to cull skills without people revolting, I'd cull L1-exploder first, then runner, then floater. Climber stays in, it is amazing and makes excellent use of the rodents-navigate-pixel-terrain core idea. Everything else gets eaten by the clam.

-- Simon

Thrown-together L2-inspired icons:



12 keys in a row are a problematic choice anyway. I discourage new players from using this. Aligning the buttons in a key-position-matching grid would force me to guess the user's keyboard layout (not hotkey choice -- the operating system's keyboard layout), and violate Fitts's law, by not aligning stuff along the screen edge for mouse users.

ccexplore, thanks for the many reasons. Unnatural merging of to-be-distinct exploders, hmm. Will ponder some more. Reasons like these is exactly why I'm throwing around loose ideas right now.

About the burner: I'd cut the assignable burner, as I've proposed to cut having both exploders in the same level. When only one or two levels rely on them, schematic usability guidelines take priority. When a whole community with many levels relies on them, that's a grown-out environment to serve.

The annoying situation right now is: We have 12 panels for 14/15 skills, that's extremely weird. Having absolute positions for these 14/15 is standard. I really want to do at least something here. Offering only a subset made sense for L2, where the entire set was much larger than the largest offerable subset.

-- Simon

Hi,

a frequent complaint by new users is how the skillset isn't sorted. Experienced users still have to look at the skillset at the onset of each singleplayer level. What shall we do now?

Sorting is generally nice, and custom sort-order dosen't seem worthy to implement. Maybe a sort-yes-or-no option that's on by default, that's okay. A full-blown sort order editor seems of too little use compared to its complexity.

[18:38] <SimonN> I'm considering dishing out a WIP version with mandatory sorting, and ask people to use that for a week or two
[18:40] <SimonN> thinking about it for several days now, the correct order in the right half is exploder-batter-blocker-cuber-builder-...
[18:40] <SimonN> and you and Clam make convincing arguments for why walker shouldn't come first [instead climber-floater-runner shall come first]; on the other hand, Fitts' law (button in corner is very easy to click) suggests walker first, and Neolemmix has it first also

But let's first see what you guys think.

I can post more considerations from IRC later.

geoo's proposal: climber, floater, runner, walker, jumper, batter, exploder, blocker, cuber, builder, platformer, basher, miner, digger
Clam's proposal
My proposal

-- Simon

I've skimmed the source.

You are already using a struct for the lemming. You can implement what I have suggested with all-public structs and normal functions. I.e., you don't need inheritance, you don't need virtual methods, ...

This is a general observation: A language is a toolbox, you don't need to use every tool.

For readable source, try to keep your identifier names in English. Comments in English are also preferred.

-- Simon

With OOP, the first idea is to have the entire play in a large class, and reinstantiate the class. Since this is unwieldy, the next idea is to have savestates as components in the game class, and go back to a savestate from the very beginning.

-- Simon

Nice one, thanks.

Picking unique things is super hard. You have to guess what level of obscurity is appropriate each time anew.

-- Simon

Once you introduce this feature, there will be constant demands for it to account for more and more different scenarios. To the end user, "if you don't like what we give you, play it from the beginning" feels even worse than not having the option at all.

This is a pure slippery slope argument without evidence so far. I don't believe that the user feels like described.

You're correct with: If the catch-all is not workable for a game, don't implement a catch-all. Aim for something weaker.

Independent levels allow a very easy catch-all.

Quote from: Simon on May 09, 2015, 01:05:44 PM

Proxima, that's not a counter-argument. If they like this reward, people will progress and unlock as designed. Using the option feels like cheating, so they won't use it.

This is simply not true. For me -- and, I suspect, for many (and this is backed up by similar discussions we have had on the DROD forums) -- the experience of playing a game is all about the counterplay of frustration and satisfaction. If a reward is available for free, achieving it the hard way is lessened. When you reach a frustrating part, if there is a way to just skip it, the temptation is always there.

I believe that you feel like so. The consequence is, you will then enjoy the game more when other people can't use some option you wouldn't want to use.

How would you feel when the author ships two versions of the game, one with unlock-all and one without, and you choose and play the one without? That's how I treat the unlock-all option. It's not part of the game.

The satisfaction doesn't come from the reward, but from having accomplished something. You can't get that by skipping levels. I assert that this is true for most -- the reward isn't what drives people. Evidence is how people spend hours and hours on games that have unlock-all, how money is a very weak motivator for programmers, and how existing unwatched youtube videos of rewards don't affect game enjoyment.

(Link please to the DROD discussion, so I can dissect. :->)

Using the option will not feel like cheating if it's offered as part of the game. (Does playing levels in any order in Lix feel like cheating to you?)

Skipping unrelated levels never feels like cheating to me, even if the game doesn't want me skipping. Who would I cheat in the first place when I know there's unsolved levels remaining?

Quote

I'm concerned with the resulting problems of locked content, once the game becomes a tool.

I suspect this is the root of our disagreement. I don't know what you mean by the game "becoming a tool". Can you explain this phrase? To me, a game is a game -- it's an entirely different type of experience from using a tool (or, for that matter, from reading a novel) and so you can't use analogies from those to argue about what a game should be like. (That said, I would certainly agree that there is a wide spectrum of different games, including some that are more tool-like and some that are more novel-like.)

Excellent awareness.

The game becomes a tool once you think of it as a data processor.

Most people will lose interest before coming to this stage. It's a late stage for most, it comes well after beating the game. On the other hand, some people are interested in hacking details much earlier.

When one treats the game as a tool acting on data (levels), not having the unlock-all option is a misfeature. The tool could easily work on everything, it's not a problem at all for it, but it jumps through extra programming hoops to prevent you from doing the normal thing. It prevents culture.

This is one reason for the unlock-all, not the only one. Unlock-all is valuable for the non-toolers.

I partly agree, but passwords can be good if combined with another system.

Passwort + save system is an interesting solution. I assume the password advances the save file, so it only has to be entered once to unlock stuff permanently.

-- Simon