Organizing and centralizing the credits

[Ranger M]

What category do people like me (mainly writers, no code or artwork contributions) fit into?

English Localization?

Maybe not, localisation is translation, and although you can improve the flow of the words, etc, in translation to suit that language, it is different from actually writing things.

Maybe a writers one? (mainline) Campaign Authors, description writers and people who contributed to the history could be included

[Noyga]

What category do people like me (mainly writers, no code or artwork contributions) fit into? Not that I think I'm eligible for the credits yet, I should probably fix up a few more mainline descriptions before that happens, but I'm wondering if there's even such a precedent.

Background contributer ?

[Eleazar]

English Localization?

Maybe not, localisation is translation...

I was joking.

I'd suggest a "General Writing" catagory for those that write the unit descriptions and Help documentation.

I believe campaign, specific credits should be displayed at the end of a campaign, not mixed in with the general credits. Not that campaigns are less important, but it's redundant. When a campaign is completed, the credits for that campaign roll, and then the general credits go by.

[Jetrel]

Ok. Now, is it enough to write who did what as WML comments next to the name (so that they are simply recorded and easy to check from the file), or should they be visible also in-game? Personally, I don't think they should be visible for the player (since I don't think it makes sense to present that much detail, that mostly would make the overall look messy, to the player), but I guess it could go either way.

It can easily be done so as not to look messy, and it must show the descriptions in-game, in at least one place.

I understand that it would be a bit awkward to show them in the "movie-style, won-the-game" credit roll, but it would not be awkward to show them in the "help->credits" listing.

My suggestion is to expand the actual WML to support that as part of the list:

Code: Select all

[about]
	[text]text = _ "Artwork and Graphics Designers" style=title[/text]
	[text]text = _ "Major Contributors" style=smalltitle[/text]
	[contributor]
		name = _ "Francisco Muñoz"
		alias = _ "fmunoz"
		description = _ "Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9."
		icon="units/undead-necro/lich.png"
	[contributor]
[/about]

Yes, this requires a code change, but it should be fairly trivial. If we're overhauling this stuff, we may as well do it right.

Any display of the credits could pick and choose which parts to use.

[zookeeper]

My suggestion is to expand the actual WML to support that as part of the list:

Code: Select all

[about]
	[text]text = _ "Artwork and Graphics Designers" style=title[/text]
	[text]text = _ "Major Contributors" style=smalltitle[/text]
	[contributor]
		name = _ "Francisco Muñoz"
		alias = _ "fmunoz"
		description = _ "Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9."
		icon="units/undead-necro/lich.png"
	[contributor]
[/about]

Yes, this requires a code change, but it should be fairly trivial. If we're overhauling this stuff, we may as well do it right.

Any display of the credits could pick and choose which parts to use.

I'd much rather not have that verbose syntax. I suggest simply letting the engine parse the line correctly, which should be easy if we just wrote all the contributors down according to a simple convention:

Code: Select all

text = "&units/undead-necro/lich.png Francisco Muñoz (fmunoz) -- Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.
...
..."

It should be easy enough to split that line into the image path, name, alias and description. This also takes up one line per contributor, Jetryl's example of WML expansion takes up six lines per contributor. I'd also much rather have styling done automatically based on the semantics, too.

[Jetrel]

I'd much rather not have that verbose syntax. I suggest simply letting the engine parse the line correctly, which should be easy if we just wrote all the contributors down according to a simple convention:

Code: Select all

text = "&units/undead-necro/lich.png Francisco Muñoz (fmunoz) -- Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.
...
..."

This is what Boucman was talking about when he accused you of thinking in terms of features rather than code. Coding a special case for what you're talking about into the C++, is a really, really bad idea.

Coding what you're talking about into a macro is a very good idea, and basically provides you with ... everything you're asking for, except that you have to put brackets around it.

The native syntax of the WML should remain as I suggested - if the native syntax were as you suggested, I suspect we would have to rewrite our WML parser for it to understand that, and that's an extremely non-trivial task, to the best of my knowledge.


Basically, the whole XML revolution revolves around doing things the way I described them; doing things with very verbose syntax, that leaves absolutely no "insider information" requirements standing. Remember that there are some things about "how things work" that only the people who built the program, or were informed by them, can modify. Every one of these is a barrier to someone new working on the program, especially if the old guys leave for some reason.

It's like commenting code; only "cowboy coders" and n00bs don't do it, and "cowboy coders" are notorious for the functional, but incomprehensible, messes people have to rewrite in their wake.

It should be easy enough to split that line into the image path, name, alias and description. This also takes up one line per contributor, Jetryl's example of WML expansion takes up six lines per contributor. I'd also much rather have styling done automatically based on the semantics, too.

Yes, the reason I suggested a logical separation between records was for styling purposes.

[zookeeper]

Code: Select all

text = "&units/undead-necro/lich.png Francisco Muñoz (fmunoz) -- Founding Artist and former lead artist, worked consistently on all aspects till around v0.7-0.9.
...
..."

This is what Boucman was talking about when he accused you of thinking in terms of features rather than code. Coding a special case for what you're talking about into the C++, is a really, really bad idea. Coding what you're talking about into a macro is a very good idea, and basically provides you with ... everything you're asking for, except that you have to put brackets around it.

Certainly, I think in terms of features (and WML) rather than the C++ code. But ok, consider my proposal withdrawn (reading what you said, I doubt anyone else would like my idea either) - macros would work just fine in this case.

Basically, the whole XML revolution revolves around doing things the way I described them; doing things with very verbose syntax, that leaves absolutely no "insider information" requirements standing.

I don't see why we would need to do things "the XML way" - we're not trying to produce "semantic documents" or even a generic game engine, we're merely trying to build a single game. As I said, I agree that my viewpoint is definitely of the user and content writer instead of coder. So from my viewpoint, it doesn't make sense to, for example, separate the contributor name and alias into separate fields just so that the game engine doesn't have to look where the parentheses are and draw the alias within in a different colour or whatnot - having the game engine do that automatically since that's how we always want it to look is the KISS solution to me. Usually removing special cases from the C++ code involves pushing those exact same things into WML (in one form or another). Sure, the special cases don't clutter the C++ code anymore, but is cluttering the WML considerably better? Also considering that the special case handling only needs to be in one place in the C++ code, whereas in WML we may need to add the special case handling to every unit, every [about] tag, etc. Of course it's better to push 100 lines of C++ code into 200 lines of WML to keep the code cleaner, but is something like pushing 20 lines of C++ code into 500 lines of extra WML still ok?

Remember that there are some things about "how things work" that only the people who built the program, or were informed by them, can modify. Every one of these is a barrier to someone new working on the program, especially if the old guys leave for some reason.

Well, that's a fair point.

[Darth Fool]

I don't see why we would need to do things "the XML way" - we're not trying to produce "semantic documents" or even a generic game engine, we're merely trying to build a single game. As I said, I agree that my viewpoint is definitely of the user and content writer instead of coder. So from my viewpoint, it doesn't make sense to, for example, separate the contributor name and alias into separate fields just so that the game engine doesn't have to look where the parentheses are and draw the alias within in a different colour or whatnot - having the game engine do that automatically since that's how we always want it to look is the KISS solution to me. Usually removing special cases from the C++ code involves pushing those exact same things into WML (in one form or another). Sure, the special cases don't clutter the C++ code anymore, but is cluttering the WML considerably better? Also considering that the special case handling only needs to be in one place in the C++ code, whereas in WML we may need to add the special case handling to every unit, every [about] tag, etc. Of course it's better to push 100 lines of C++ code into 200 lines of WML to keep the code cleaner, but is something like pushing 20 lines of C++ code into 500 lines of extra WML still ok?

Remember that there are some things about "how things work" that only the people who built the program, or were informed by them, can modify. Every one of these is a barrier to someone new working on the program, especially if the old guys leave for some reason.

Well, that's a fair point.

The initial work between coding it to work on a single line and doing it via jetryl's suggestion is probably about equal. The big difference in C++ as jetryl pointed out wil be in the maintenance. It is fine to assume that we have the final style for how we want to display credits, but we will probably be wrong. A year from now, someone will want even more improvements etc... The other reason to do it the way jetryl suggested is not for C++ support, but to make it easy to create and maintain a script to translate the about.cfg into html. The nice thing about zookeepers now withdrawn proposal would be that all or at least most of the work on formatting decisions is pushed out of the C++ code and into the hands of the WML writer. This obviously would be easier to maintain in the C++, but harder for the wml->html conversion. I am not yet sold on one way over the other. I will have to wait until I get back to staring at the credits code before I decide which is best.

[Eleazar]

It seems to me the major impact on future flexability is not how chunks of text are associated with a style, but weather styles can be created and modified without changing the C++.

I would have made a proposal like zookeeper's, it certainly seems more user friendly. Of course i can't weigh the WML vs C++ maintainance issues.

[torangan]

It's the same as to why formats like XML get widely used now. Having a verbose WML Syntax may seem cumbersome but it's easy to understand just by looking at the WML and can easily be converted with Scripts if the Syntax changes somewhat. For C++ those things don't hold true at all. The code gets easily hard to read and when you port it over to something new it's very easy to miss a special case, introducing a subtle bug.