Idea to remove the limits of the current terrain system

Brainstorm ideas of possible additions to the game. Read this before posting!

Moderator: Forum Moderators

Forum rules
Before posting a new idea, you must read the following:
Post Reply
Dominikus
Posts: 15
Joined: June 28th, 2006, 1:39 pm

Post by Dominikus »

SkeletonCrew wrote:
Dominikus wrote:and chaning the internal terrain-type from char to int should be no problem either.
That judgement is based upon what???
I got to with unicode-portation at work often. The most heavy part is converting the string-functions (search etc), but all ugly cases like single graphemes consisting of multiple characters should not occur with terrain-types, do they? - thus I concluded that it would be easy.

What do you do internal with the terrain-type that makes it not easy?!?
Dominikus
Posts: 15
Joined: June 28th, 2006, 1:39 pm

Post by Dominikus »

mog wrote:The main problem when using unicode is not the editor but the keyboard.
For things like entering a text I would fully agree. But for a map, simply open a character-table. This is not so different from clicking the desired type in the graphic editor.
mog wrote:For purposes other than user-visible text, one should IMHO restrict the used characters to 7 bit ascii. It's the least painful way for contributors.
A nice decision few years ago - that makes it so easy to change to utf-8 now, because we have not the problem with ambigous meaning of the high 128 byte values in different charsets.
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

Dominikus wrote:
SkeletonCrew wrote: That judgement is based upon what???
I got to with unicode-portation at work often. The most heavy part is converting the string-functions (search etc), but all ugly cases like single graphemes consisting of multiple characters should not occur with terrain-types, do they? - thus I concluded that it would be easy.

What do you do internal with the terrain-type that makes it not easy?!?
"Dear lord, we thank you for granting us the patience to deal with people who do not read the whole thread."
SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Post by SkeletonCrew »

Darth Fool wrote:"Dear lord, we thank you for granting us the patience to deal with people who do not read the whole thread."
Amen.
SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Post by SkeletonCrew »

I've been working on the system and slowly it starts to work again :) The branch still has glitches but making good progress at the moment. So it's time to look ahead to step 2 changing the single character based system to something new. I looked at the proposed idea's in this thread and there are 3 options to choose from. Since I'm not a major user of the system I'd like to hear the opion of the real users of the system. So I'll list the idea's with some comments and like to hear the options others have. If there's an idea to change the system not mentioned here then let me know.

Here's the list in order of appearance:
1. The orginal proposed idea with the lookup table
This idea is vetoed, since it removes the limit partial and the other ideas remove the limit totally.

2. Zookeeper's idea for UTF-8
PRO
- high backwards compability
- in the proper editor still 1 char is 1 tile
- unlimited terrains
CON
- glyphs are harder to enter
- glyphs can be harder to reconize
- maps can be screwed up when opened in not UTF-8 editor

3a. Jetryl's idea with the multiple letters in comma seperated lists
With this idea we can easily change the letters to a new letter and make them a bit easier to remember. This requires all letters to be at least 2. _If_ we choose for this idea we'll discuss which letters for what, no need to do that upfront.
PRO
- can redefine all letters so they are better to reconize
- unlimited terrains
CON
- harder to make backwards compatible, but has to be done
- the 1 letter is 1 tile no longer exists, still there will be the option to pad data with spaces so the map files still look 'good'

3b. Jetryl's idea with the multiple letters in comma seperated lists
We can keep the old letters but use a comma separated list. I'm not really if favor of this idea since it will get difficult to be backwards compatible. So unless somebody has good arguments for it this will also not be the winner.

These are the options, so have fun with them :)
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

I am very happy to hear that you have got the internals working. Believe me when I say I understand what a major bit of work that is.

My preference would be a multi-character comma seperated map where spaces are collapsed (ie they can be used for visual cues but have no meaning) and where in the characters are restricted to letters and numbers. Convention might have it that the first letter be capitalized and symbolize the generic type, but this would not be enforced in the code. I dislike UTF-8 because we DO have people who use non UTF-8 editors, and it is a lot easier to come up with a convention that Vh is a human village than trying to figure out what an o with an accent is supposed to be or some random 4 digit number. Of course, that is subject to interpretation, but the key point is by restricting ourselves to a 26 character set it is still not hard to have as many terrains as we need and still have map that is readable in every editor outthere. I would also like to see numbers not used in the letter scheme, and made to be used exclusively for indicating starting sides. This way it would be possible to start a side on any type of terrain, and not force it to be a keep.

Assuming a comma seperated list, I think a reasonable convention for mainline terrain would be to use the proposed three letters with the first letter indicating the base terrain type (village, mountain, etc...) and the second two as modifiers. Heck, some basic terrains could still have no modifiers as long as trailing space is eliminated. This will require changing a little in the code to deal with shroud, but should be straightforward. A perl (or some other type) script will need to be written to convert old maps to new maps, but this is not difficult, and there are several people, myself included, that could do it once a convention is established. I would suggest that the script naturally makes makes the comma seperated list 1 extra space wide to allow for placing numbers, something like:

Code: Select all

Vha ,Gaa ,Mmm ,Kcc1,AAa ,asgg
two letters might be enough for mainline terrains as I think it unlikely that we will end up with more than 26 variety of villages, but of course by having a comma seperated list, it could be expanded later.

So I guess I am voting for 3A modified a bit.
SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Post by SkeletonCrew »

Darth Fool wrote:I am very happy to hear that you have got the internals working. Believe me when I say I understand what a major bit of work that is.
Yes now working on the fixing the last issues and starting to test.
Darth Fool wrote:

Code: Select all

Vha ,Gaa ,Mmm ,Kcc1,AAa ,asgg
Personally I think trailing spaces shouldn't be allowed but only leading spaces.

Code: Select all

Vha, Gaa, Mmm, Kcc1, AAa, asgg
At least *I* think that's more readable, but still I'm not using this stuff a lot.
mog
Inactive Developer
Posts: 190
Joined: March 16th, 2006, 2:07 pm
Location: Germany
Contact:

Post by mog »

I second Darth Fool's posting.

Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.

[edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]
Aurë entuluva!
SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Post by SkeletonCrew »

mog wrote: Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.
I like the wildcard idea, not super easy to implant but I can really see the use for it.
mog wrote: [edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]
Code technical it's no problem to allow them leading or trailing but it was meant to enforce uniform maps.
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

SkeletonCrew wrote:
mog wrote: Additionally, I'd like to have some kind of wildcard in the WML terrain matching code, so you can use e.g. V* instead of Vha,Vhb,Vex,Vdy,... to match all villages. But if the rest of the code works, this should be quite easy to implement.
I like the wildcard idea, not super easy to implant but I can really see the use for it.
mog wrote: [edit]
Concerning leading/trailing spaces: I think spaces should have no syntactical meaning. While I agree that leading spaces are easier to read, this should not be enforced by code.
[/edit]
Code technical it's no problem to allow them leading or trailing but it was meant to enforce uniform maps.
Actually, where I could imagine it being enforced would be if somebody decides later to make saved maps pretty, but that would only be an output thing. during input, spaces should be stripped completely. I don't care one way or the other on whether it should be trailing or leading.

As for the wildcard idea, that is something that would be very good. I have an idea to change the way the map builder handles probability to fix some bugs that is waiting on the new system. The wildcard would certainly fit in with that. Basically, the use of symbols as wildcards and other functional tools is one reason I would like to reserve the legal terrain characters in WML to be only 26 letters, allowing symbols to later be reserved for hardcoded effects like wild cards or something else.
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

Skeleton Crew, thanks for working on this. :D
Darth Fool wrote:So I guess I am voting for 3A modified a bit.
I strongly agree, with these additions:

* "/ | \" These symbols should be allowed for bridges. The direction indication is just so natural.

* Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.

I can't decide if a case-insensitive system would be overall better or not.

I'd probably come back from my hiatus to work on the WML side once this was ready. I don't believe much (other than this) has changed in terrain since i last was active.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
SkeletonCrew
Developer
Posts: 787
Joined: March 31st, 2006, 6:55 am

Post by SkeletonCrew »

Eleazar wrote:Skeleton Crew, thanks for working on this. :D
Eleazar, good to see you here :) (If you wouldn't have shown up I would have pm'ed you.)
Eleazar wrote:
Darth Fool wrote:So I guess I am voting for 3A modified a bit.
I strongly agree, with these additions:

* "/ | \" These symbols should be allowed for bridges. The direction indication is just so natural.
I agree, this is one of the things I had in mind, but I didn't want to start with these details before the decision was made which way to go. _If_ we go for 3a I'll post a proposal with the details. With mog's idea for wildcards I've got some new idea's ;)
Eleazar wrote: * Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.
I thought of them, but the tab distance can also differ per program, that's why I didn't post it. I don't have the font 'problem' with vim ;)
Eleazar wrote: I'd probably come back from my hiatus to work on the WML side once this was ready. I don't believe much (other than this) has changed in terrain since i last was active.
I don't know, guess Darth Fool knows whether something has changed. Would be nice to see you back :D
freim
Retired Terrain Art Director
Posts: 1113
Joined: November 29th, 2003, 11:40 pm
Location: Norway

Post by freim »

Eleazar wrote:Skeleton Crew, thanks for working on this. :D
Darth Fool wrote:So I guess I am voting for 3A modified a bit.
I strongly agree
Ditto
User avatar
Jetrel
Posts: 7242
Joined: February 23rd, 2004, 3:36 am
Location: Midwest US

Post by Jetrel »

SkeletonCrew wrote:
Eleazar wrote: * Tabs should also be allowed as a "padding" character. Because in most fonts characters vary in width, with some editors tabs could create much more uniform columns.
I thought of them, but the tab distance can also differ per program, that's why I didn't post it. I don't have the font 'problem' with vim ;)
I agree with SkeletonCrew, and disagree with Eleazar - tabs are very, very variable in size; so much so that most text/code-editing programs have a thing in the preferences to set just how many spaces a tab represents, and have utilities in them to convert tabs to spaces, and vice versa. Tabs have no clearly defined standard for computer screen width.
Eleazar wrote:in most fonts characters vary in width
However, every operating system has a mechanism to use fixed-width characters in it's basic text editors. Most even default to this.

On a mac, you simply set your font to Monaco, or Courier. Poof - done.


I very strongly vote against using tabs; they are an extremely bad idea. Granted, they should just be collapsed like all other whitespace (except return/newline), which means that people could actually still use them :P, and we wouldn't be doing anything to stop people from using them, but... we should at least conventionally not use them.
User avatar
Eleazar
Retired Terrain Art Director
Posts: 2481
Joined: July 16th, 2004, 1:47 am
Location: US Midwest
Contact:

Post by Eleazar »

Skeleton Crew:
If it's not too hard while you are working on this, see if you can get things to work with terrain files in multiple subfolders. The terrain folder is getting unmanagably large, and will certainly continue to grow once more terrain codes are allowed. I don't remember what the technical obstacle was to putting terrain in different folders, possibly it's no longer an issue.



Tabs:
In a decent text editor you should be able to set the width of tabs. It doesn't matter if everyone has the same amount of space between the terrain codes, as long as everyone can get the columns to line up. Maps that use spaces AND tabs would likely be bad.

If we had terrain codes of different lengths in a map (We used up too many of the readable 2 digit codes and need to start using 3 digits, for example) tabs would be more convenient than spaces because 1 tab character will create the right amount of space, even if you change the length of the terrain code. In other words with spaces you have to edit the terrain codes and the spaces in between, but using tabs you only have to edit the terrain codes. A minor but noticable advantage.
Feel free to PM me if you start a new terrain oriented thread. It's easy for me to miss them among all the other art threads.
-> What i might be working on
Attempting Lucidity
Post Reply