Bike/Wall selection Gui

[philippeqc]

I still think it would be cool to have a naming convention for folders in the moviepack like moviepack/mod_name/ & /moviepack/bikename/

What is the difference for you between a mod and a bike??? With the lack of order, we have seen contributions that where full mods (arena textures, sounds, bike model, bike textures), partial mods (arena textures only, uses the default bike), bikes (just the bike model) and skins (that are made for a specific bike).

People seem to want to mix and match everything, allowing for all possible combinaisons. And that makes a mess.

One organisation of this would be:

Code: Select all

/media/mods/mod_name/
                     textures.*
                     sounds.*
      /bikes/byke_name/
                       model
      /skins/skin_name/
                       skin

This would allow so much mix and match, so much configurability that it would siken most people. Except for a few zealots that would download all the skins, all the models, nobody would see the game in the same way.

That people are able to pick their own model works nicely when the environment is "fixed", a la FPShooter. In aa, there have been some mods that had the full details, including the models. It could be an alternative to favorise theses. Personnalisation could be the skin that gets associated with your bike, rather than the default skin.

Following such a model, one organisation would be:

Code: Select all

/media/mod_name/
                sounds.*
                model.ase
                textures.*
                skin/
                     defaultSkin
                     flames
                     skulls

where 3 skins are possibles, defaultSkin, flames and skulls (how original!)

One advantage of this organisation is that it limit customisation to a sensible selection. Also, it goes with an idea that servers could advertise that theme/mod to use there. On the _bad_ side, it doesnt permit to have along each other flying genitalias, nazi cross, old bikes, new bikes, and vehicules from the latest movie. On the _good_ side it doesnt permit to have along each other flying genitalias, nazi cross, old bikes, new bikes, and vehicules from the latest movie.

Overall, what I want to point is, what kind of look are we trying to acheive? As I've presented here, I believe that allowing for all combos will only be chaotic, dissatisfy people and in the end be a waste of effort, while the "mod" combo would allow for more uniform look, while permitting some customisation and personnalisation.

But do not limit yourself to either of these. I'd be interested to know how YOU see it. And also, tell us how you would organise the files.

-ph

Nota: A friend of mine pointed out that moviepack doesnt mean anything, unless you already know what it is. So I've used the label media. Love it, hate it, its just a suggestion! ;)

[n54]

i think the last idea is the right direction to go

i'm going to be detailed here, bear with me i will try looking a bit into the future as well, the examples are just examples.

i'm very slowly progressing on a theme i've been working on on and off for a long time (having ME (or something very similar) makes me extremely slow) and i'll use it as an example even though it might never be completed.

first of all i call it a theme because it is aiming to change the visual experience, nothing else. for me the word mod (short for modification) has more to do with changing all/any feature of the game (think for example half-life mods).

a "complete theme" or "fully themed" would to me be a collection of files that change absolutely everything graphical:
- the intro screen
- the fonts
- the model (not necessarily a bike as we've already seen in some themes)
- the trail texture
- the wall textures
- the sky textures
- the floor color and texture
- possibly even the game icon (both the shortcut icon and the titlebar icon)
- sounds (almost forgot)
and possibly in the future (included to show more than the tip of the iceberg):
- theme hud graphics (and maybe theme default on/off choices though this probably belongs outside the theme)
- theme font size settings (this needs to be seperate for each theme as they will be able to use different fontfaces)
- chat area limits (debatable but imo theme-dependent because the themes will be able to structure/place the hud differently)
<del>- chat area server message levels (this one should be in user settings, sorry)</del>
- menu background/transparency/border settings & possibly files
- root menu background choices & files (as opposed to ingame menues)

there will always be the possibility of more as the decades march on, some issues that arise from this is:
- expandability
- having certain settings set/kept within each theme so that the player does not have to change settings all the time if switching themes
- enabeling the player to customize settings (and possibly even placement of hud components etc.) in the theme

however a theme does not have to change all this, it can change only certain aspects of these visual parts and still be a nice theme (as many of the present ones do)

now to using my own example, my aim is a "complete theme" and then some. I had everything worked out until i started modelling so when that is finished i think i'll need to change all the other stuff again. anyway, the "and then some" part consists of the following:
- several models for the same theme
these will be the same model but at different "resolutions". i know how the model will be (at the point of adjusting my vertex sketches right now before i once again start trying to climb blenders learning curve lol ) and i will make three versions: one with 128 vertexes suitable for online gaming (a bit less than the present widespread original low resolution moviepack), one with about 200 vertexes suitable for lan or local (not started), one with about 500 vertexes or more for artwork rendering (not started). this last one might be released seperately but it still makes me think a bit about how this should be integrated into a theme.
- environment textures in different resolutions
the most usual texture resolution is 256x256 if i remember correctly, i aim to include a full set of textures for at least the resolutions 256x256 (min) and 1024x1024 (max), perhaps one at 512x512 as well.
- multiple model textures
firstly the different model resolutions will in themselves require differently scaled textures but in addition to that i've been thinking of having different textures available for the looks of the models

there are other things too but this suffices to show the problems:
- is it just one theme?
- can the structure allow such huge themes and/or should it?
- how to avoid a mess, either a mess of subfolders or a mess of files that want the same names?
- what about the freedom for (other) themes not to do any of all this stuff?

here's my proposed solution with arguments/explanation of my thoughts, first folders:

armagetron/themes <----- the parent folder

armagetron/themes/default/ <----- the always-included shipped theme

armaegtron/themes/edge/ <----- just another theme *oh it happens to be the name of the theme i'm working on*

to explain: an armagetron subfolder named themes in which each theme has it's own seperate subfolder. if for any reason the game cannot find a needed file in the chosen theme it will "borrow" said file from the the default -- hold your questions about "what if the default theme doesn't have a bike model in resolution xyz?" the problem is evaded later. all the default graphic files are collected within the default theme folder.

onto the files in each theme... first of all i propose a few changes to the already existing settings.cfg file used in the moviepack. it has been used to set the floor color which is nice but it is also well suited for storing the settings for more complex/elaborate themes: which model is to be used, which textures to be used etc. <-- not a complete list but simply the (default for theme) settings first time it is opened, and later reflecting any choices made by the player for that specific theme. themes could also provide a settings.bku "backup" of the default settings but this would be totally voluntary of course.

naming convention for themes:
completely free as long as it has multiplatform support for folder names. and yes the default theme does not need to be named default as long as the program equates the two names, it could simply be named armagetron.

naming convention for files:
here's the tricks i'm thinking of... i'll make an example out of models

models filetype: .mod or .ase or future supported model files
models naming: name, then filetype prefix, then filetype for example: "N347 'Guppie' Velocitator.128.bike.mod" (yes it's the name of the edge theme "bike" lol ). this might not really be necessary for the models as i think the game won't need any other models than the "bike" model but one never knows, anyway it will be very useful for other graphical files than the model. i put the .128. in there as part of the name, it could be used as a browsing criteria but i think such fidelity is a step too far for now.
with an ingame theme browser:
when a theme is chosen (always in off-line mode) the computer simply looks for all supported model files within the theme folder and the resulting finds is what the user can choose among in any ingame preview
without an ingame theme browser:
the user must change the setting manually in the theme settings.cfg or using a console command so that it points to the correct filename
if the file is not found:
the game reverts to the default model file in the default theme (not caring one bit about "resolutions"). if the default model file in the default theme is not found either it will give the same error message as it already does if you try starting the game without those files.

but what if i want the model from that other theme?
both an ingame theme browser and console commands should be able to handle it using full path names starting from the armagetron directory, it shouldn't require too much additional code and i think the freedom is a good thing. however if this isn't implemented one would still be able to make ones own theme folder with the bits and pieces from where one wants it (but this is far too reminiscent of todays moviepack situation and i don't like that to be honest). for the in-game theme browser one could have an "all" choice which looks for all supported filetypes for the choice in question in every armagetron/themes subfolder it finds.

this is especially important in relation to trail textures. i don't know about the rest of you but i have at least 30 different trail textures in my moviepack folder, as it is today i have to rename files to switch lol i want my "insertnamehere.trail.png" structure

yet another example, this time arena walls:
edge.high.a.rim.png
*YIKES!* well... from right to left: png is a supported filetype for arena walls, the game is looking for rim textures and specifically the one that goes in place a, and yes high because this theme has different textures for high and low rims (but the computer doesn't necessarily need to care)

to sum it up the game looks for the different files that are all in the theme folder in a backwards manner: formats, typenames, etc. moving from the back to the next punctuation mark snipping up the info as it goes (makes for a nice little loop of code). this is a backwards hierarchical naming convention i guess and what the game looks for doesn't need to be the same for every file but it does need to be the same for every file that is meant to fill an identical function.

will this make simply browsing the theme folder from an OS a nightmare? slightly but not really more than for let's say an old style winamp skin.

avoiding unnecessary cpu cycles:
- perhaps the game can compile a list of all themes and content on startup and push it to a file for fast access later? reading it into and out of a multi-array structure i guess... maybe it simply isn't needed
- not allowing theme changes during a game, at least not an online game - once again maybe not?

answering all the questions i raised:
ok you're probably as exhausted as me by now but i'll try to tie the loose ends...

expandability: i think having a main folder with all files following an information rich naming convention as well as allowing "almost" full path naming allows for total expandability and a lot of freedom. the file naming convention is for the computers benefit and is even overrideable by the full path naming (in my head )

theme dependent settings: one should be careful about what is included or excluded here, one does not want this and user settings or general settings to either conflict or override each other. some stuff clearly belongs here imo

player freedom of choice: i hope the ideas given so far increases this and ease of use

is it just one theme?: perhaps not when thinking of what i'm working on but i think all the mentioned will apply none the less. i might split my work into several related themes but there will for example still be choices like model resolution available within each.

can the structure allow such huge themes and/or should it?: i think the structure can, or that to degree it does it should be allowed to, but yes when/if one gets to have enough choices that it could make seperate themes on their own i think one should do that - 15-themes-in-1 doesn't make practical sense. there is little to worry about in terms of duplicating data, many themes already share the same model for instance.

how to avoid a mess, either a mess of subfolders or a mess of files that want the same names?: no subfolders or subthemes in this suggestion, and imo the file naming convention suggested makes the group of files less messy.

what about the freedom for (other) themes not to do any of all this stuff?: some graphics will be needed by default, others not. i think the fallback solution to the default theme combined with the ability to either scrounge off other themes by fullpath naming in the theme settings.cfg or by building on other themes (and including the unchanged bits from that/those) makes for freedom to make very small tweaks. it depends somewhat on the license of the other themes of course but i for one will use a cc license and i don't think it will be a problem. in addition some things could simply be turned off (like the hud) in a theme.

ok that was my thoughts, hope i didn't turn anyone reading into a zombie craving brains. of course there are other good solutions possible

[SuPeRTaRD]

anohter way to do it might be stuff everything in /moviepack/ folder, & in the .cfg file(s) have something that looks like:

cyclemodel: lady_xlr8.ase
wheelmodel1: ladyx_fwl.ase
wheelmodel2: ladyx_rwl.ase
wheelmodel3?: blahwheel.ase
model placeholder:
model placeholder:
model placeholder:
model placeholder:
model killzone: recogniz.ase
etc.

skins & trails could also have config pointers

however, with a sub-directory naming convention for the bikes, i can download coolbike.zip, unzip it to the /moviepack/ folder, it ends up in /moviepack/coolbike/

& then with a few programming tricks i know nothing about..

anyone with /coolbike/ could see each others bike when they play

thats not that important to me tho.. personally..

i already know how to replace stuff in the game bikes anyways
I'd like to see the ability to toggle winzone/killzone in the gui & toggle killzone tank/recognizer graphics & AI... blah pipedreams plus i'd have to model a tank i digress

[philippeqc]

I havent forgotten you, I just needed a bit of time.

Am I wrong if I split what has been proposed in two parts? There is the theming of the application, and the theming of the arena.

Theming of the application
Have the possibility to affect the way the application looks and maybe behave. This would include the
-fonts
-spash screen
-chat (area font)
-menus
-HUD
-application sounds (intro music, beeps on the menus, etc)

Theming of the Arena
Affect the in game elements
-model(s) of this theme
-skins
-trace/trails
-floor
-rim
-ceiling
-in game sounds (vehicule sound, turn sound, crash sound, etc)

The idea of theming the application is nice. In my opinion, that should not be affected by other's decisions ie: connecting to a server doesnt change any of this.

On the other hand, for the theming of the arena, many ideas have surred over time. They regroup in two fondamental, quite opposite ideas. Now the question is what is the philosophy desired.

Should it be a big individual "mix and match". Each client using its own set of rim, floor and ceiling. Every player is displayed by a model of his/her own picking.

-OR-

Should it be a more uniform, server propagated, theme, where all the clients would use the same rim, floor and ceiling, and the models are limited to a subset within the theme.

How do you see the game evolving? If you had to pick only one alternative, what would it be?

-ph

Forget details such as "how files are transfered"

[Lucifer]

Should it be a big individual "mix and match". Each client using its own set of rim, floor and ceiling. Every player is displayed by a model of his/her own picking.

-OR-

Should it be a more uniform, server propagated, theme, where all the clients would use the same rim, floor and ceiling, and the models are limited to a subset within the theme.

I think a webpage is the right model to follow. You have something that specifies *all* the graphics to be loadled and where to place them. If the browser can't find one, it uses a default value (the alt text, only in AA we can have a default graphic instead).

Consider cascading stylesheets. That's about what I'm thinking. So the end-user can put his own, supercede the server's with his own, or whatever. I'm very much interested in preserving the player's choice.

[philippeqc]

I think a webpage is the right model to follow. :) You have something that specifies *all* the graphics to be loadled and where to place them. If the browser can't find one, it uses a default value (the alt text, only in AA we can have a default graphic instead).

Consider cascading stylesheets. That's about what I'm thinking. ;) So the end-user can put his own, supercede the server's with his own, or whatever. I'm very much interested in preserving the player's choice.

Wow, there I was, separating concepts as I saw an exclusion in them, and in a few lines, you marry them again perfectly, and make me like it.

But it feels like quite a complex system to implement.

Anyone has a different model.

-ph

[Lucifer]

Wow, there I was, separating concepts as I saw an exclusion in them, and in a few lines, you marry them again perfectly, and make me like it.

But it feels like quite a complex system to implement.

lol.

Logically, it's not that complex. You just have to loop everytime you load something instead of just loading once. You could use XML to describe the arena, then just have a priority list by the player. So in a config file you might have:

ARENA_SPEC_LOAD_FIRST player
ARENA_SPEC_LOAD_SECOND server

The player would specify that preference, nad it means he prefers the server's graphics to his own locally-installed pack. (this is just for illustration, you can easily see how to scale this up to n graphic sets)

Then the game would first load the xml descriptor for "default" (it always loads default, default is what initializes the entire tree). Then it would load "player", then it would load "server". In each iteration of the loops, it *only* loads the data structures that appear in the file, so previously-defined data structures that don't get overridden would persist. And each file gets loaded into the *same* data structure, so that new data overwrites old data.

When it's done, we have this mish-mash of files listed somewhere in memory. Now we just iterate through the whole thing (it'll probably be a DOM, numerous code you can rip to walk the tree) and load files just like a browser does.

Writing an xml parser with expat is extremely easy, and there's a DOM version somewhere. I can show you Python code that does something similar (and is ultimately targetted at the same logic I just described).

So logically it's very simple, at least.

(If I had about 100 hours of time to spend, I'd port AA to pygame so I could use Python in it and write cool stuff like this)

(I intentionally left out how to load files from the server, but it looks pretty clear that you'd use a fileloader object, and then you can just create new objects of different types. Start with a filesystem object that uses the local filesystem and make it work with multiple moviepacks as they are now, more or less. Then make a new fileloader object that retrieves with http or whatever, post your pack on a website and add to the protocol sending the information from the server, or whatever. Plenty of ways to go from there, once you have the file loading object off in its own class, separate from the layout object I spent most of this post describing)

[SuPeRTaRD]

"I'm very much interested in preserving the player's choice."

me too!

i think if custom graphics are implimented, they should be off by default, & the concentration should be on a good fps, on a default install, though

since lots of people play this on legacy machines with voodoo cards & whatnot..