Talk:Feature list

From Sokoban Wiki

Jump to: navigation, search



I found a new tooltip effect, with Stylesheet(CSS).
It is useful to show extra information of each feature in Feature_list.
This saves space in the tables and it will only show the information when one makes mouse-over on the word 'info'.

In fact the idea of the info-text, is to clear the table of the additional and very well detailed information.
The info-text, alone they are shown with modern browsers(as Internet Explorer 7, Opera 9 and Mozilla), the other browsers usually shows the extra information in the cell of the table. This is this way, for reasons of compatibility with all the browsers.

In SokobanWiki Template Tip:

Additional information

Template Tip (HTML):

content : Content of the tooltip. The initial text is 'information'.
text : Text of the tooltip. The initial text is 'info'.
style : Individual stylesheet for the text.
width: Customizable width(pixels) for the tooltip.
menu: Customizable menu option for the tooltip. Values: yes or no.

Basic templates (24 January of 2007)

  • Template:Yes

<span class="box-yes" style="color:rgb(40,128,55);"><span class="box-yes-text"><font color="#288037"><b>yes</b></font></span></span>

  • Template:No

<span class="box-no" style="color:rgb(205,92,92);"><span class="box-no-text"><font color="#CD5C5C"><b>no</b></font></span></span>

  • Template:Un

<span class="box-un" style="color:rgb(0,0,128);font-size:8pt;"><font color="#000080">{{{1|unnecessary}}}</font></span>

  • Template:Ni

<span class="box-ni"><span class="box-tip"><span class="box-tip-2"><span class="box-tip-menu-no"><span class="box-ni-text">n{{{1|/i}}}</span></span><span style="min-width:{{{3|0}}}; width:auto; color:rgb(57,57,57); background-color:white;">{{{2|Not implemented}}}</span></span></span></span>

  • Template:Tip

<span class="box-tip"><span class="box-tip-2"><span class="box-tip-menu-{{{menu|yes}}}" style="{{{style}}}">[{{{text|info}}}]</span><span style="min-width:{{{width|0}}};">{{{1|information}}}</span></span></span>


Template "Tip"
Hello Solido.
This new css is great. It works fine now. Thank you very much! Matthias

Use of Stylesheets(CSS)

You can allow the use of the style sheet(.css), so that it is possible to be added styles and classes for the page.

SokobanWiki Style:

To enable User Style, the following two settings have to be enabled through LocalSettings.php:

$wgAllowUserCss = true;

User Javascript customization requires that your wiki administrator sets a configuration variable in file LocalSettings.php:

$wgAllowUserJs = true;


2006/07/21 8:30 CEST

Both variables are now enabled! ;-)



All our table styles don't works at "Internet Explorer 6" ! But this is necessary for the majority of all users...


Hello Solido.
The display in IE6 is still not very good. What do I have to do for fixing this ?
Matthias, 26.01.2007

About the CSS Bug in IE6.
The problem of the styles in IE6 and IE5, is caused by the bad implementation of browser to the new rules of CSS 2.1.
Template TIP works with browsers modern that interprets CSS correctly (as Opera 9, Firefox, IE7).
This solution of tool-tips, was only thought to work with rules CSS 2,1, old others browsers will only see the version without format.

PNG Images

Hi Solido! First many, many thanks for your massive commitment at the Sokoban Wiki! Now, between I have changed the CSS and the tip-template too. How can I add the word "unnecessary" to the unnecessary-expression in the common CSS and will all working correctly after deleting the old yes,no and unnecessary templates, what I plan to do? Can we use also PNG images for the current used GIF images at the same place or will it makes crashes like before..? Will it be possible to make a litte hidden border at the right site of an (YES/NO/UN) image for an optimal distance to the following text (inside of the CSS)? Many thanks! Is it possible to use relative links (in the CSS) to the images instead of the absolute ones?


Feature-list in sub-pages

In the beginning, the feature-list like idea to show characteristic simple of the soko-programs, work very well.
But with the help of the programmers and users, this list was growing, with more details and options that current offer the different programs.
Today is a big list and with but detailed features that shows the immense quantity of options that the programmers can make to give a better product to the soko-community of internet.

An idea to manage the giant feature-list, and thinking of all the future inclusions; to improve the functionality, an option is the division of the list (the sections) in sub-pages.
An example is the list of next Firefox Feature_Brainstorming.

This has their advantages, to the power to reduce the size of the pages, to improve the navigation and to allow the inclusion of a glossary, extra information(as Feature-info) and possibly a SokRFI(Sokoban Requests for Implementation) for each section.

For an easy maintenance also a list of topics as Feature_Menu can be included as template in each page.


Ok, I finally think it's a good idea. Hence, I vote for sub-pages. Anyone who doesn't want to divide the list for any reason ?
Matthias [21.01.2007]

That is a possible way to manage the feature list. The width is no problem - at least my monitor can display it (resolution: 1600 * 1200). The list is very huge regarding the height. However, it's easy to scroll through the list. We carefully have to think about a division.
Here are my comments to the advantages of division:
1. Reduce the size of the pages: That's right, of course. However, yet the whole page is loaded fast enough, I think.
2. Improve navigation: Well, here it's difficult to say what is the best. I think all features on one page is easy to navigate because you just have to scroll up and down. If there are many pages you have to follow a link, return from that link and go to the next one. The current page allows a search for key words in the whole feature list. On the other hand it may be clearer to read having every section on an own page.
3. Glossary, extra information and SokRFI are really good reasons for extra pages. But it's also possible to have a little link inserted into every section for that information so the current feature list can stay as it is now.

I'm still looking for something like a tree. That is: there is a "+" in front of every section and if you press it it becomes a "-" and the tree below it opens (like in some explorers). Unfortunately I haven't found a way to do that, yet.

Maybe dividing is a good idea. If we divide then we have to think which sections get an exta page. The "platform" is very important, I think. If someone just picks another section he maybe doesn't see that the program won't run on his OS ...

The list in general gives a general view of features, the users are not necessarily interested in all the topics.
Imagine, a new visitor in the page, maybe not this interested in observing all the tables, alone some sections (in those that it considers important).
A division proposal can be :
Page 1: Platforms, Limits, Game Types.
Page 2: Game Play
Page 3: Customizing
Page 4: Skin Features
Page 5: Map Viewing

When dividing in sections (pages), the users that are interested in a topic specify, they can go directly with a click to the page.
Additionally the extra information, in each specific page, it can be practical for the visitors, to avoid the constant navigación with pages with related topics.
The use of a menu of topics, is also functional so that the user, only observe the sections that interest of the list.
Example the section Feature_Multiplayer
I want to remember that this idea of dividing the list, is alone a possibility, a suggestion.

Ok, I see the advantages.

I have copied the advantages / disadvantages from the Wiki:

Sections vs. separate pages vs. transclusion

Advantages of separate pages:
* what links here feature * separate edit histories * automatic redirect on renaming * redirect to a section is not possible * loading a small page is faster than loading a large page * can separately be put in categories * with Semantic MediaWiki: have separate annotations
Advantages of one large page with sections:
* loading one large page is faster and more convenient than loading several small ones * searching within one large page (the page itself or the wikitext) with a local search function is faster and in some respects better than searching several pages (for which one has to search the whole project); also the TOC provides for convenient navigation. * enforces the cohesion of a concept that while having several definitions needs independent editing.
An alternative is composing a page of other pages using the template feature (creating a compound document by transclusion). This allows easy searching within the combined rendered page, but not in the combined wikitext. Titles have to be provided.

If a complete list is still needed it's possible to create it by including the articles. For example this is included from "The_rules_of_the_game":

The objective of the Sokoban game is to move objects (usually boxes) to designated locations by pushing them.
These objects are located inside a room surrounded by walls. The user controls a pusher called "Sokoban" which is said to mean something like "warehouse keeper" in Japanese.
The pusher can move up, down, left and right, but cannot pass through walls or boxes, and can only push one box at a time (never pull).
At any time, a square can only be occupied by either a wall, a box, or the pusher.

It's also possible to display a date of the last change which may be easier to look after than "recent changes". Most users just want to know if there is something new. (only in Mediawiki 1.8 and newer): 08
Having sections this information can be used in every section.

Thanks for reordering the programs!!! I have to think about the name "JSokoApplet" vs. "JSokoApplication". I only support the application anymore because the applet has to many restrictions.


Is interesting, the possibilities of MediaWiki 1.8 with regard to the composition of pages.
You will remember, from the first list, until today, the growth in one year was giant.
And in the future, this will surely grow even more, because the human invention power is always infinite.
Some forms exist of reducing the size of the central page, as well as to organize the categories well; (an idea can be to organize in related groups).
The page "Feature_info" was created by the necessity of knowing more information, example... now in the table the shortcuts are included, but it is an extra information, the same as the note "flaw:".
They are data useful, but many times there is not the space to insert the extra data, and without filling the cell excessively.
Some programmers, maybe want to write a note, shortcuts, the limits of each feature, etc, and not only a simple "yes" or "not."
The solutions are for who look for them.


Feature candidates

Please, put all the new suggestions here to be discussed.

Feature: Copy to clipboard all the better solutions

In general the puzzle challenges, have the objective of finding the best scores, in specific measures( moves, pushes, box pushes, box changes and pushing sessions). When a player competes in these challenges, he makes many solutions, many records of a puzzle. The quantity of variants of solutions can be big.

An option to Copy to clipboard all the better solutions (the best in each type), with a click can be very useful.

Optionally a small reference of the measures can be included, when it is inserted in an e-mail to send to internet.


It may be useful, and actually, my own YASC program already offers it for best-moves and best-pushes solutions ("open" window->menu->copy to clipboard...").

But note that such a feature is closely related to ""Autosave best solutions". In fact, it doesn't make sense to elevate it to a feature unless the program automatically keeps track of the best solutions for each metric.

So if this feature should make it to the list, I suggest doing so by splitting "autosave best solutions" in 2:

  • autosave best solutions - moves and pushes
  • autosave best solutions - secondary metrics

I think it may be ok to add this to the feature list, but I'd like to warn about going further down the statistical alley. Statistics should not be blown out of proportions and become dominating, neither in a program nor in a list of features, especially in a domain like this one, where it really is very few who cares.

sld wrote:
> Optionally a small reference of the measures can be included, when it is inserted
> in an e-mail to send to internet.

Please note that YASC has this option (Settings: Control - Snapshots - Include secondary metrics in titles). When enabled, the solutions and snapshots have all 5 metrics in their exported titles and not just the moves and pushes, that is, in the form "Solution m/p/l/c/s".

This is a "nice-to-have" feature, but it's also a good example of something that falls below the threshold for what is worthwhile to put on the feature-list. In other words, there will always be a large undergrowth of features that the users highly appreciate but won't show up on the feature list.


Feature: builtin solutions

Maybe we should add a feature like "builtin levels". Otherwise the feature "builtin solutions" is without connection to anything (-> solutions for what ?)

- Matthias

Good idea. Just don't pin it down to a number of builtin levels because that is too dynamic for maintenance in the feature list. It's better to limit the information to yes/no.


Good or bad features

As a comment to one of the editings, Matthias Meger wrote:
> deleted note for "automatically move to next level"
> (the note is correct, but is true for many features. The user may decide by
> himself when reading the list)

I think it's a mistake to organize the list based upon "the reader may decide for himself" because most of the readers won't have the insight required to differentiate what constitutes a good or bad feature.

The reader will automatically think, that if something is on the list, then it must be a good thing. This is also true for the vast majority of the features, but that also makes it extra important to clearly indicate where something may be controversial or considered an "anti-feature".

Inserting such warnings is related to adding notes like "less is better", or "bigger is better" to a statistical overview to help the reader immidiately recognize what is good and what is bad.


> not all people will agree that this is a positive feature unless it's optional.

I agree, that it isn't an important feature. However, we have to pay attention that such notes aren't added to much more "features".

"autosave best solutions"
This is a good feature. But one could say, that it may be bad feature if the old solutions are overwritten by the new best solutions, so the old solutions are lost and couldn't be used for a comparison.

"deadlock detection"
Some might say that they don't want to get such hints/help from a program and consider such a feature as a bad feature.


Different people may see several features differently. If there should come more such features which are "worth" a note I recommend to add a * or something like that and give a short description in an extra article about that features.

I don't know if it's possible or expedient to mark the "standard and very useful" features differently in the list than the "additional less important" features. Maybe we can use slightly different colors. However, the best way to deal with this topic is just adding really good features to the list :-)

I added a link in the "test" article "additional info test". I think it is a good idea to give a short description of some of the features. These links are colored blue which let them look more important, unfortunately. Maybe we can change that so they are colored black, too.


I got a mail from a reader of the Wiki making a suggestion:

Similarly, there is a feature in the Game Play section called "Show box/goal/player numbers".  Since Sokofan is  
already established as the only game on the chart so far that can play the numbered Sokoban and Multiban 
variations,  why is this field needed?  It should go without saying that a game that allows you to play numbered 
Sokoban would show box and goal numbers!!

I think we should think about that when consolidating the feature list.
- Matthias

I have also always meant it was a silly and superflous line.

Solido put it there, and I have often disagreed with his threshold for what is worth putting on the list. In my opinion, his threshold has often been too low, as if his only criteria was "does a program do something, then it must be on the list", not considering relevance or importance.

Other examples are some (but not all) of his "one-click ..." and "quick browse..." lines which also are far below my personal threshold. However, opions may differ widely here, so it's often impossible to agree on which lines deserve to be on the list.

I assume that this particular line with "show/hide numbers" was put on the list for no other reason than the fact that Sokofan offers it, and it's lovely to get some reader feedback, saying the it's not worthy to be on the list.

With this reader feedback, I think it's justified to remove the line, and I'll do so having finished this post.

The quote from the mail started with the text " Similarly, there is a ...". I'm very curious about which other items "similarly" refer to!


I believe that the feature 'show box/goal... number', in fact for the 'Player Mode' this doesn't have relevance, since in a principle, when it was inserted, it didn't exist the sections SokoFIR and EDIT Tools. As always the features, they are proposed, suggestions... they are not decisive neither demanded to the programmers.

If I believe that 'show box/goal.. number' can have utility in the 'EDIT Mode', like form of control of the editor, to see the position number.

But as you they know, Sokofan doesn't have 'Edit Mode', so this feature is retarded, until this it is implemented in Sokofan.


Programs that appear on the feature list

A question about Feature list, so that a program appears in the list. That characteristic must have these? Exist limits?.

Programs like YSokoban and EasySok, can have a space, on that depends that they can appear in the list?


I vote for to add only programs which are for free, not for programs, which are shareware. I would also only add programs, which are living, which are in developement each time. So I think, that especially SokoMind... is dead, no development here since many years, no interesting features... For my opinion, only SokobanYASC and Sokofan are really important games for our list, but I can also accept additional sights.


I find it important to add shareware and commercial programs too. Otherwise, a lot of users and programmers will think that the free programs are inferior in quality compared to shareware and commercial programs, even though the contrary is true. Currently, there are very few shareware and commercial programs that get even near the quality of the major free clones.

Also, I don't think a program needs to be under active development in order to be on the list. If a program is good, if it's available, and people like to use it, then it deserves to be on the list just as much as any other program.

Any serious clone deserves to be on the list and they all cast light on what one can expect to find in a Sokoban clone. Apart from the already included clones, I'd very much like to see JSokoApplet, YSokoban, Sokoban for Windows, SokoStation, and SokoMind on the list.


Freeware games versus commercial games

I vote for, to bann all shareware games at the list, because I think it cannot be our mission, to push any commercial products at our Wiki..


Without the shareware programs, the list cannot document that the free programs are at least as good as the commercial ones. Therefore, it would be a big mistake not do include the shareware programs. If they are not listed, it is far too easy for them to claim that they are so much better that it's worth paying for them.

(It's not that I think there is anything wrong in making money from selling Sokoban programs. It is only that I mean the users and the potential customers deserve to have the best information at hand before they pay for a product, in particular in the Sokoban case, where many free implementations are work "con amore", and therefore often are at least as good as the commercial products.)


Additional Tools - Solver : Solver Type

@Brian: "Solver settings and options depend entirely on the plugins, not the host program"
You are right - at least for the programs currently in the list. JSokoApplet is an exception. I agree that "solver type" is misplaced in the feature list.
Regarding the other listed solver programs in the Wiki (excluded sokoban++ which is already in the feature list) I consider them all to be "just" solvers.
It's maybe a good idea to describe the abilities of the solvers in a new article at some time.

- Matthias

Windows small fonts and large fonts

Hi Brian. Large fonts forces problems with some programs. Sokoban for Windows has problems resizing the skins correctly with large fonts set. The feature for resizing is there, but can only be seen with "normal size" fonts.

- Matthias

Fine, in this context I only find it preferable to call them "small fonts" rather than "normal size fonts" because the latter easily can be understood as if a program is legally excused to support small fonts only. Windows offers both "small fonts" and "large fonts", and therefore a conforming program must support both sizes. (Custom settings are also possible, but then I would say it is debatable whether a user rightfully can expect a program to handle it gracefully.)

Actually, in my opion most users are better served with large fonts which have better readability than small fonts. Unfortunately, the average user will never notice that there is a choice, and therefore Microsoft, in my opinion, has made the wrong choice by making small fonts the default setting.


Personal tools