Moving to two-letter terrain codes

[hands]

http://www.wesnoth.org/forum/viewtopic. ... 6&start=30

Tile letters currently available:

http://www.idi.ntnu.no/~haskjold/wesnot ... tters.html

There has been talk about using two-letters for each. We will do something about it when we run out

I don't know that it needs to be implemented immediately. After all, there has been talk of changing the terrain coding system for at least a few months now. I just think it's best to have a plan before you need it. And, I have seen enough work being done on terrain in my short time here that it would seem advantageous to do something sooner than later. While I definitely don't know all of the options that have been talked about before, I have an idea or two that might help with moving forward while retaining backward compatibility with each release.

I wouldn't use any of the non-alpha characters (!@#$%^?*&) for terrain unless absolutely necessary (or if there is a justifiable reason). If you move to a two-letter system, there is room for over 2700 different terrain types and that doesn't include using special characters. Special characters could be reserved for possible future needs that aren't currently foreseen (though I don't have any idea what they may be).

Maps made with a two-letter convention could simply have the first line reserved to indicate what terrain system it was based on. Map readers and editors could use a script to look at the very first character of a map file to determine whether or not there is version information (which would indicate that the map should be treated as two-letter) or if the map should be treated as "v1.0" (one-letter convention). The first character of a new map could be "=" or "#" which don't seem to be in current use, and that would indicate a later version than the one-letter convention. If the map being read is based on the old (current) map system a translation script could create a new map file that could either replace the outdated map or be used temporarily.

[hands]

There are more terrain ideas in this thread and this thread.

[hands]

Allowing for version numbers to be in the map file could help in more ways than one. One example would be if a layered tile system gets implemented. v1.0 could refer to the old/current one-letter system. v1.1 could refer to a two-letter system being implemented prior to having multiple layers. v1.5 or v2.0 (or whatever) could refer to a two-letter system with two layers.

This would allow older maps to be usable in any version of the game, and the map editor could even have a compatibility feature to save maps in a way that would allow them to be used in older versions of the game.

[Jetrel]

unless I'm mistaken, a compatibility system is needless complexity. The trick with our versioning system is that new stable versions completely replace old stable versions. All of the content is upgraded to fit the new version - it's like a super-sequel, in some ways. It includes new content, but brings the old content up to par with the new engine.


Thus, when we release a Wesnoth 2.0 that is as stable as Wesnoth 1.0, there will be no need for Wesnoth 1.0 to exist.

This is not unlike what Mozilla does...

[Eleazar]

I agree that it would be a bad idea to have multiple concurent systems for defining terrain at the same time. However when introducing the new map system we also need to have a plan on how to get the hundreds of current maps upgraded.

hands, if you wish to add something to a tread when no one has yet replied, it's probably best to hit "edit" and add the content to your previous post.

[hands]

I wasn't really trying to imply that the 1.x versions of the game should be maintained at the same time as the 2.0 version of the game. The comment about creating a 1.0 compatible map after 2.0 had been released was probably stretching things a bit. I guess I'm just a little too used to proprietary products that people don't automatically upgrade due to cost reasons.

My thoughts were more directed toward the fact that there will be quite a bit of 1.0 compatible content that might not be entirely compatible with whatever terrain system is in use during version 2.0. There might also be a desire for people to change the terrain system prior to that point. It is also possible that people might want to release campaigns that can't be GPL'd for whatever reason, and those might become outdated even though they could contain some excellent content. Therefore, it would make some sense IMO to allow for some backwards compatibility within the program so that people don't have to worry whether older content is compatible. All content would remain compatible (at least from the standpoint of the terrain system).

A compatibility script should be fairly simple to write as well...

check first character of map file

if(char=="=") ##the "=" could be replaced with any symbol
check version#
match map version# to terrain system
(use filter if necessary)

else(run compatibility filter from version 1.0 to current)

I really don't know how to code, but that should give you the gist of what I'm thinking. The latency in opening even an older map should be less than a second and even less for current maps.

Another use for a version number within the map file could be a terrain version number. In this day of massive hard drives, retaining multiple versions of terrain doesn't seem out of the question. Older versions of terrain could be made a separate download if there is a concern about download size. What the terrain looks like now, and what it will look like with version 2.0 doesn't necessarily seem to coincide. Developers could have a choice of which version to use.

[scott]

It might be easier to just make a WML key under [scenario] and [multiplayer] to tell the engine what to expect. It can become obsolete as single letter maps fade out.

Automatically converting maps is super easy. You could even run the script on the campaign server, or more realistically some campaigns would be 1.0 compatible and others would be 1.1 compatible (since the branches are diverging now).

[Viliam]

I agree that it would be a bad idea to have multiple concurent systems for defining terrain at the same time. However when introducing the new map system we also need to have a plan on how to get the hundreds of current maps upgraded.

An idea (inspired by how did UTF-8 format extend ASCII while keeping much of backward compatibility)

Select a character not used yet for terrains (or only very rarely used). This will be the "start character". Select any other character as "end character". The map files will be parsed by the following algorithm:

* Read the following character in the input stream (skip newlines and spaces).
* If this is not a "start character", return this one character.
* If this is a "start character", read the following characters until the "end character" and return the string between, removing spaces from the end of string.

For example, if "start character" is ( and "end character" is ), this is an example map file:

ab(cd)(ef)gh

And this is how it gets parsed:

a
b
cd
ef
g
h

Advantages of this format:
- backwards compatible (all old maps can be parsed)
- allows 2-letter, 3-letter, etc terrain symbols
- you can easily edit files in plain-text editor, if you pad them with spaces like this:

(a )(b )(cd)
(ef)(g )(h )

[hands]

It might be easier to just make a WML key under [scenario] and [multiplayer] to tell the engine what to expect. It can become obsolete as single letter maps fade out.

I haven't made any scenarios or campaigns. I've only played around with the map editor. So, my thoughts and ideas are a bit more geared towards that. What I have suggested is pretty much the same as yours--to have a "key" of some kind--it's just in a different place. Absence of a key would indicate version 1.0 or earlier content that needs to be filtered, while the key itself could indicate any number of versions (including 1.0 content that has already been filtered and converted).

From what I've read there is a possibility of WML in older content becoming outdated as well. I would really hope this doesn't happen, but that's not for me to decide (or do anything about since I can't code). There are lots of examples of old games/content that people don't want to give up just because it's not the latest and greatest. Even old Atari or NES games can be loads of fun regardless of the graphical capabilities of the system. PS2 is successful partly because they made the decision to retain compatibility with older games. I think that Wesnoth will be successful regardless of how it retains compatibility with older content.

Automatically converting maps is super easy. You could even run the script on the campaign server, or more realistically some campaigns would be 1.0 compatible and others would be 1.1 compatible (since the branches are diverging now).

My point is exactly that converting maps should be super easy. It is so easy in fact that a script could be added directly to the game. That way you don't need to worry about 1.0 compatibility or 1.1 compatibility or even later compatibility. Adding a key somewhere is just a mechanism to try avoiding compatibility issues. There are more ideas about maps on the table than just how many terrain tiles are available to be used. Multiple layers and animations are other possibilities that might benefit from the engine being able to recognize a version key. Even if there is just a message that the content is old and incompatible, that is much more graceful than "ERROR: unable to recognize content/character" or whatever.

I'm a big fan of "timestamping" things especially when I'm working on an evolutionary project. It seems to make it much easier to reuse older work rather than have to scrap and rewrite much of the time. It doesn't solve everything, but it can sure help sometimes.

[hands]

An idea (inspired by how did UTF-8 format extend ASCII while keeping much of backward compatibility)

Select a character not used yet for terrains (or only very rarely used). This will be the "start character". Select any other character as "end character". The map files will be parsed by the following algorithm:

* Read the following character in the input stream (skip newlines and spaces).
* If this is not a "start character", return this one character.
* If this is a "start character", read the following characters until the "end character" and return the string between, removing spaces from the end of string.

This is another method that would work just fine. However, one of the things that people really seem to like about the current map system is that it is quite easy to edit in a text editor. So, to retain that the text file would need to have the start and end characters around every tile space including the single letters. Instead of every tile consisting of one or two characters, it would consist of four characters, or the file wouldn't be very usable in a text editor. Admittedly, I don't personally have a problem with a larger text file. Storage is a much smaller concern than it used to be and bandwidth is becoming less of a concern. I would make the map editor create the start and end characters for every tile in maps created after this was implemented. It could be quite cumbersome for someone to manually add all of the start and end characters to a text file though.

There are definite advantages as you have mentioned. One more advantage that I would add is that a text map file would probably be much easier to read with brackets around each tile than by counting characters.


There is another option to make double character maps easier to read in text files, but it would require the use of a key (which I have tried to argue isn't necessarily a bad thing, and could have multiple uses) for backwards compatibility. It has been mentioned that a placeholder/escape character could simply be added to all of the single characters such as a->.a, and I would suggest that a space (or two) could be used between each tile for visual clarity (a space is much easier and faster to type than "()").

Code: Select all

         #1.1        #1.1
rRR  ->  .r.R.R  ->  .r .R .R  or  (r )(R )(R ) 
rtg      .r.t.g      .r .t .g      (r )(R )(R )
grr      .g.r.r      .g .r .r      (g )(r )(r )

            =1.5          =1.5
AaabbA  ->  Aa ab bA  ->  Aa  ab  bA  or  (Aa)(ab)(bA)
aqgrst      aq gr st      aq  gr  st      (aq)(gr)(st)
Aa.aab      Aa .a ab      Aa  .a  ab      (Aa)(.a)(ab)

         %1.0          %1.5          %2.0
sdf  ->  .s .d .f  ->  As Ad Af  ->  Aws A.d A.f
lkj      .l .k .j      Al Ak Aj      A.l A.k Azj
ert      .e .r .t      Ae Ar At      A.e Apr A.t

Edit: I learned how to make things line up decently, and I added a couple more variations.

Please forgive me if you think I'm being a pain in the @$$. I'm really just trying to get some brainstorming going on because it's easier to KISS if you make a plan ahead of time rather than try and fumble through when things get awkward. I hope I'm helping rather than annoying.

[WanderingPaladin]

Using an escape charater to denote a new terrain type would also work without modifying existing maps.

[hands]

The problem with that is that the developers have already stated that they would rather not use the symbols beyond what is pretty much on a standard keyboard. So, even though the terrain set could be bigger than it is now, there could come a time when the character set becomes limited again, and at that point multiple characters is really the only way to go. Everyone might disagree with me, but I think that planning for backwards compatibility is a good thing. It is especially so if the solution can be quite simple.

Reading the text file would also be more awkward.

[WanderingPaladin]

It would only involve using one special charater, then all the other alpha characters could be re-used. This would double the number of terrain types. Use of another escape character would triple, and so on. And I don't see it being harder to use a text editor except for alignment

ttttrtttt
tttrttttt
ttrtttttt

becomes (using ~ as escape character)

tttt~ntttt
~htt~nttttt
t~h~nttttt

[hands]

I didn't say that using a text editor would be impossible by any means, just awkward (alignment).

You're right that just by using an escape character, the number of possible terrain types would increase by 52. However, much more could be done with multiple character systems (two fairly simple methods have already been proposed within this thread that would easily allow for as many characters per tile as needed).

One idea that I rather liked was assigning a letter (or possibly letters) to a climate type. So, the first letter could indicate a climate/weather type, and the second letter (with the first letter) would match to a terrain type.

Example of first letters:
A,a,B,b,C,c -> Winter ... Aa could be a hills village in winter
D,d,E,e,F,f -> Spring ... Da could be a hills village in Spring
G,g,H,h,I,i -> Summer ... Hi could be a multi-tile mountain in the summer
J,j,K,k,L,l -> Fall ... Ki could be a multi-tile mountain in the fall
M,m,N,n,O,o -> Desert/Drought
P,p,Q,q,R,r -> Marsh/Flood
S,s,T,t,U,u -> Indoors
V,v,W,w -> Future use?
X,x,Y,y,Z,z -> Custom use per scenario
Various different things could be used. I also like good/evil possibilities.

Using this example you could have six times the number of possible terrains within each climate type than are currently available. The beauty of this option is that just by changing the first letter of each tile, the map would be quite different while still retaining key geographic points. An alternative that would still allow for multiple climate types would of course be to code it into a WML key in the scenario file. If someone wanted to make a VERY large map though with different climates throughout, using the map file is much more reasonable. There could even be a climate brush in the map editor.

The terrain artists may not like this idea at all because they might take it to mean that they are required to make multiple versions of every terrain type, but not all terrain types would change much with climate. An artist might even decide that a certain terrain type would never change with climate (a very high mountain might always be covered in snow.

Also see this thread for a different variation.

[ILikeProgramming]

Just put all two-char terrains in ()'s such as (AaBbCc)