So here's part 2. It's a lot and it's kind of a mess, since I've spent so much time with some parts of it and wanted to get it posted finally, so some parts are more detailed than others.
The order doesn't have any background.
2. UINo, I'm not asking for a prettier UI, I want to create a pretty UI myself.
2.1. Image scalingProblemAt the moment you have to do all the calculation yourself when creating UIs, which includes images. This can be a problem, with different screen resolutions, if the image isn't big enough.
SolutionIt would be cool to be able to have a fixed box-size for the image, but being able to change whether the image should be stretched to fit the box, or being kept as it is. (CSS contain and cover)
But this would need two more options to work properly:
keeping the aspect ratio of the image or changing it to fit the box
where to position the image (for both axis, horizontal and vertical: start, center, end)
2.2. More units for position and sizeProblemThe only way of setting size and position of an ui element at the moment is to set the percentage of the space it takes of the axis, that's a problem when creating a square for example. You can't just set the same percentage to width and height because it's relative to the axis, which differs if you don't have a 1:1 aspect ratio.
SolutionMore units. Again, I'm referring to CSS where you have
- vh (view height - percentage relative to the height)
- vw (view width - percentage relative to the width)
- vmin (percentage relative to the smaller axis)
- vmax (percentage relative to the bigger axis)
- % (percentage relative to the containers same axis you change the value for)
But I'd also add something like
- %w (percentage relative to the container width)
- %h (percentage relative to the container height)
as relative units and
as absolute unit.
Sure, there are even more, but those are probably the more important ones (ignoring font related ones like "em" and "rem").
Why absolute units? (pixels)For example as padding or a border you sometimes want a absolute width no matter what resolution you are on, or if you want a image to be it's full size but not being stretched (because of quality loss) you could just set it's width and height to the original images size.
I know that's covered with image-scaling, but it's just an example.
2.3. mathsWhy?For example to define a start-position to something like
((3*buttonWidth)+(4*borderWidth))
What?- (+) addition
- (-) subtraction
- (*) multiplication
- (/) division
- (%) modulo? lol
- (round) rounding value x to n decimals
2.4. min-width/height, max-width/heightWhy?Having definitions like
width = 10%
min-width = 100px
max-width = 300px
so the element is set to a width of 10%, but if 10% is less than 100px it's set to 100px. If it's more than 300px, it's set to 300px.
2.5. Something similar to CSS media queries (adaptive design instead of responsive)Why?If someone is playing on a different aspect-ratio than 16:9 you might want to layout the UI differently, which isn't as easy atm.
What?CSS has media queries which allow you to change styles depending on (min/max)
aspect-ratio, (min/max)
width/height,
orientation (if someone is playing 9:16, lol),
resolution (something like pixels per inch) and a lot more. But those are probably the only needed ones. (at least aspect-ratio and width/height)
2.6. positioningWhat?- Instead of (or in addition to) start- and end-positions there should be start-positions and width/height
- Padding and margin would be pretty neat as well
- Positioning relative to sibling elements
positionX = ElementID.positionX + ElementID.width + 10px
Why?width/height instead of end-positions is a must-have to reduce calculation while creating UIs.
margin might not be pretty important since you can just change position and width/height, but padding would be useful for images and text inside of containers to prevent those reaching the border of the element.
positioning relative to sibling elements could be useful when sizes change and aren't static all the time. (which would be nice)
2.7. Events and Functions for UI elementsProblemWe are pretty limited in what buttons and stuff do, we just set a id to the element and that's it. No way (None I know about at least) to bind custom functions to a button.
SolutionInstead of setting a ID to give a element a function, there could be a few events in which you can call a function or create a own one.
Event examples:onClick
onMouseEnter
onMouseLeave
onMouseHover
onSelect(item)
For Checkboxes, Dropdowns and similar stuff
onCheck
onSelect
...
Function examples:OpenUI(uiID)
Testing
Race
Replay
Garage
...
AddClass(ElementID, Class)
RemoveClass(ElementID, Class)
ChangeLanguage(language)
SetBikePaint(PaintID)
Exit()
ExportResult()
If we could rewrite some functions like the race result export function, it would be pretty neat.
2.8. invisible elementsI guess I don't have to explain that, just adding a style option to make a element invisible, so you can toggle the visibility without having to re-create the element.
2.9. change backgroundWhat?It would be cool if you had the option to change the menu background (where you see your bike) to different predefined scenes (or could even create own ones).
I don't know how the background really works, but having some small maps where you can see your bike in
different poses would be cool.
For example a map with just a small jump with your bike whipping (and the rider on it of course) and being able to see it from every side (like you can rotate the camera in the current background with the bike stand). Or one shredding some whoops, one with the rider just sitting on the bike, or whatever.
The bike could be
dirtier in some scenes as well, so you can see your bike in race conditions.
The standard bike stand scene shouldn't be replaced of course, it should just be additional scenes you can choose.
Speaking of the bike stand scene, it would be nice, being able to turn off the rider, so just the bike is visible.
Why?It's just a visual improvement, not necessary, but cool.
And I know it's possible to change the background already and I think it's working through maps (not sure though) but afaik it's not possible to change the pose of the rider and the bike to something else than the bike stand.
2.10. change and create elements on eventsReferring to Events and Functions for UI elements I'd like to be able to change and create elements on these events. This would make the UI files a lot more readable as well. afaik changing elements on hover and click is done by naming for example the color "color2" and "color3". That's no clear naming, instead I'd suggest Json similar syntax which I'll talk about later.
2.11. elements focusable (controller support)I explained that in my first post already, where I talked about binding. You should be able to add a line like "focusable" on UI elements and then have a bindable function to iterate through all the elements with the "focusable" line ("next focusable element", "previous focusable element") in the order they are defined.
2.12. more changeable UIs and HUD / own UI pages/HUD elementsfor example:
yes, you can change gear a bit already and the pitboard as well. But it's always the same format, I'd like to be able to do stuff like writing my time in a circle or right to left, whatever. Even if it's dumb.
So it would be nice if you just had variables which you could use in EVERY UI file.
Variables like "profiles[]", "profiles[].name", "activeProfileID", "currentBike", "currentBikePaint", ... Just everything we can see in the UI.
There are also a lot of variables which are available in plugins, using them in the UI language might be cool as well.
2.13. videosIt would be a nice addition to have videos just like bitmaps. For example as a background.
2.14. Polygons, ellipses and linesDon't have to see a lot about that either, but it should be possible to not use the whole ellipse but cut out a rectangle or triangle out of the ellipse.
Lines should be possible to make tilted as well.
2.15. use variables and classes (for text, color, ...)variables should be a value which can be stored, changed and used. Like saving "10px" as width, or saving the string "test" to insert as content.
classes should be a few styles which can all be applied to multiple elements. Styles defined in the element itself should overwrite class-styles.
Example:
className = {
width = 10px;
height = 30px;
color = #00ff00;
}
A nice addition would be to use values from another element (I mentioned that as relative positioning), like "elementID.color"
2.16. display steam group tag in front of nameSo you don't have to put your team name in your steam name and the tag is limited to users who are in the group.
2.17. add nation to displayI've read that suggestion somewhere else, I'd like it a lot.
2.18. separate stuff (manufacturer, kit, ...)I think it would be useful to provide separated manufacturer, model and color variables for kits, helmets, boots, bikes, ... so you could add multiple dropdowns for it.
(bike - manufacturer: MSM, model: 450xf, color = paint)
(boots - manufacturer: Alpinestars, model: tech10, color: black)
I know, not everybody might like that, that's why I said just providing variables for it.
2.19. reload button in bike selectionSo there is no need to switch to another paint and back to the changed one again while creating a paint.
Possible to achieve ourselves if we'd get the possibility to have functions.
2.20. search function (tracks, bikes, paints)Again, through functions and using variables from an input field we'd be able to do this ourselves.
2.21. using everything everywhereInstead of having predefined buttons for a page it would be better being able to use everything everywhere. Goes with the "bike+rider inspect view thing" as well. (Using it on every menu screen if you wish)
I'd also like to have this view just as a element, so it's downscaled to the size and doesn't contain the whole screen.
2.22 conditional stylesstyle being dependable on variables. Like making the text red if the string contains "Honda", or underline the track name, if you don't have it installed.
2.23. defining elementsI'd suggest to remove the button element or change it so it's more unique. But I think every element should have the options a button has.
Indeed I think we need just a few elements and have the real stuff that's changing it inside of it.
Like every element should have a name, position and size (always a rectangle) for sure, but also optional things like background (for a background-color), events (onClick, onHover) and content (to make it a container). So pretty much like a HTML div (sure, other HTML elements can do this too, but divs are most commonly used), which can be almost everything with the right CSS and JS.
A container can then either have more elements, a shape (another rectangle, a line, a polygon or a circle, which then has either a fixed color or a sprite to draw), text or a tooltip.
Would be perfect if it was possible to create own elements which consist out of another (or multiple) elements and just has own defined variables to change. I'll use this on the syntax example under "readability".
stackable containersnot sure, if already possible, there are "button"s inside of "item_button"s, but I guess you can't stack it deeper.
change children on parent-elements events (onClick, ...)If I had a container which acts as a button I'd like to change all the children elements on a onClick event sent by the container. (for example changing the color of each children)
2.24. better display of server missing modsI think just a "*" isn't the best way of marking a track as missing, so coloring it or something like this could be better. (or a variable "hasModInstalled" --> see conditional styles)
2.25. readabilitydo onHover, onClick, ... instead of sprite1, sprite2, ...example:
- onClick = {sprite()}
- onHover = {sound()}
- onClick = {
hide(ELEMENT_ID);
joinServer(ServerInfos);
}
json like syntaxhere (pastebin) (https://pastebin.com/x8T2Ukc2) is an example, I just came up with. It's a lot more lines than the current language, but a lot comes from brackets through deep containers. And a lot of it could be shortened by using element templates (if added), but I wanted to show more of the stuff I mentioned.
And I think it's a bit better readable. Especially if you had syntax highlighting for it.
There might be some things there, I didn't mention here, but no very important ones.
I'm not 100% sure if this would be a usable UI, since I haven't tested it (I mean, I have no way to test it currently) but I think it's kinda realistic stuff.
Maybe my syntax sucks, it's just my thought, not a must.
2.26. instead of changing the UI language replace it with HTML/CSSI know that's a lot, if some stuff is planned to implement, I'd be glad to help, for example with writing a parser for all the UI language stuff (If the language is changed. I'm by far not as good with C/C++ as with C#, JS,... but if wished I'd try), or just something else. But I know it's unlikely you hook up a random guy helping with
your code. :D
-Jonas