Templating spec.
A templating language has multiple parts.
First is resources:
For this, ini file format and CSS format seem both to work.
Second is style:
For this, ini file format and CSS format seem both to work.
Third is accessibility:
For this, ini file format and CSS format seem both to work, though they both have limitations. The ini file format has the advantage here I think.
Fourth is layout.
[*] What component you want to go where.
Both ini and css are really horrible for this. I know that the HTML style gurus tell us we should do all our layout in CSS, but frankly, it stinks for layout: it's a style language, not a layout language. They want us to munge in all these four elements of templating into a single format, and it just doesn't work.
Something visual is needed here. HTML tables are semivisual.
Since we want to be portable, I regret I shall not be allowing exact pixel positioning. It'll probably be gridbag, which is rather like HTML tables.
I understand and sympathise that this will make skinning harder, and there will be alignment issues between components eachother and the background in all platforms.
I feel this is less bad than claiming we can make components have a consistency that we can't.
I'm currently imagining a textbased descriptor, like this (the current chat layout):
[ TextArea1 ] [list1 ] [ TextField1 ] [(list1)] [Label1] [TextField2] [TextField3] [Button1] [Button1]
That is nice and visual, and if I could get something like that, I'd be happy.
As a HTML table, that would be:
<tr><td colspan=4> TextArea1 </td><td rowspan=2>list1</td></tr> <tr><td colspan=4> TextField1 </td><!-- list1 cont. --></tr> <tr><td>Label1</td><td>TextField2</td><td>TextField3</td><td>Button1</td><td> Button1 </td></tr>
But HTML is awfully wordy, and it seems better to keep the layout restricted to just showing the layout.
Even something terser:
TextArea1 | list1
TextField1 | "
Label1 | TextField2 | TextField3 | Button1 | Button1But then, if we've got a line delimiter, and a marker to say "carried on into this line", why not the same for columns? So maybe:
< | TextArea1 | > | > | list1
< | TextField1 | > | > | v
Label1 | TextField2 | TextField3 | Button1 | Button1or:
TextArea1 | > | > | > | list1 TextField1 | > | > | > | v Label1 | TextField2 | TextField3 | Button1 | Button1
That then resolves the problem of stuff where spaces get munged (such as display by HTML clients), since the above is functionally identical to:
TextArea1|>|>|>|list1 TextField1|>|>|>|v Label1|TextField2|TextField3|Button1|Button1
I'd appreciate people's thoughts on this, suggestions for better, preexisting ways to describe layout, and suggestions on good ways to parse it.
Reading around the topic, there are a few technologies out there that might be useful here.
On the face of it, thinlet is the only one worth looking at, but even that might not be what I want. After all, I will be rewriting Thud in other languages - Flash, etc. If I do that, I'll need to reimpliment that class in those languages.
So, it might be better to make something that's trivially simple so that it can be easily reimplimented in those other target languages.
[Edit: oh boy, there's LOTS: http://java-source.net/open-source/xml-user-interface-toolkits ]
Styles are also a pain. Font components in Java are specified in real-world measurements (points). Other components are specified in screen sizes (pixels).
This means that a layout specified in this way will change depending on the screen resolution of the viewer, and on their system's interpretation of how many pixels there are in an inch.
So, should skinners be able to specify all components in pixel sizes, and have the applet try to get as close as it can by fiddling with the font sizes?
Or should they be able to specify the font size?
Or should they be able to choose?
FWIW, I don't think skinners need to be able to specify the font size, just the font and colour. Of course, when picking your skinning technique, let's hope it's something that'll work when the game is rewritten for Flash (or whatever comes next)!
Blog
Website
Headstrong Games - unique board games
Have you considered only skinning the board and pieces? Full skinning (which will no doubt be implemented as well) is likely to be too client specific.
Even with this cut down skin, there will be three skin types: 2D, isometric and 3D.
Full skinning is more of a vanity exercise. It is also wasteful of resources - both programmer and computer. Thinking of all the skinned sites and applications I have used, I can't think of a single example where I wouldn't have sacrificed the skins for better quality in other areas.
To put it another way - skins should be near the bottom of the todo list.
This and 38p still won't buy you a Mars bar.
I'm broke. ThudGame is free. Server hosting costs. Skins can be sold.
Thus, skinning is not only high on the todo list, but critical. Though, any other ideas for value-adds I could add in that people would be willign to pay for would also be awsome.
2p won't cover the hosting
Well, obviously you won't be able to sell skins to me.
But in all seriousness, skins tend to be things created and shared by users, not created and sold by the developer. If you can pull it off, then kudos to you. However, the only way you will make it work is by keeping the skinning code closed -- which kind of defeats the object.
Maybe I should go and buy Illiad's book, then I could give better advice. I speak of http://www.moneyforcontent.com/ - one example of a) making money from content while b) giving the core product away for free and c) keeping your ethics intact.
If you make the game popular enough, you should be able to support the bandwidth with low-key advertising, and sell ad-free membership to those who want it. Then you can start tacking on the extra features for members. Off the top of my head, I can't think of any other ways to make money from this.