For the Parkour goal the following graphics are needed:
If someone would like to make that, please do so.
- Goal picture graphics, these we need to have general anyway. Thus also for rules and environment objects(different colours?).
- Checkpoint graphics, can also be particles, whatever looks good.
- Also some indication that a checkpoint is the start/finish.
If someone would like to make that, please do so.
Concerning the goal picture: We haven't agreed on a general goal picture design yet.
If noone has a better idea, I guess we just stick with the "picture on brown background square"?
If noone has a better idea, I guess we just stick with the "picture on brown background square"?
That was the policy so far and it worked out with if giving a nice background.
Sadly enough though I always have to get these graphics - especially if like in Hazard a different background is used.
I therefore propose using the rulegraphics as a kind of "overlay", where the backgorund is specied as a rulebg.png or something and saved in the Graphics.c4g folder - similar to the HuD-Elements. Then graphics could be more flexible and the background design would rather depend on the whole design of the pack/round.
This would need a bit of enginecoding to do though :/
Sadly enough though I always have to get these graphics - especially if like in Hazard a different background is used.
I therefore propose using the rulegraphics as a kind of "overlay", where the backgorund is specied as a rulebg.png or something and saved in the Graphics.c4g folder - similar to the HuD-Elements. Then graphics could be more flexible and the background design would rather depend on the whole design of the pack/round.
This would need a bit of enginecoding to do though :/
Why do things always have to be made complicated?
The whole point of a symbol is recognition. In this case, the brown background told you it's a goal. Recognition gets worse if you change things around, so having pink-colored goal backgrounds in your scenario is not a good idea.
It's also annoying because whenever you'd want to draw a goal symbol somewhere (Think of menus, inline in text, as overlays, etc.), you'd have to fetch the background separately and make sure it's drawn.
The whole point of a symbol is recognition. In this case, the brown background told you it's a goal. Recognition gets worse if you change things around, so having pink-colored goal backgrounds in your scenario is not a good idea.
It's also annoying because whenever you'd want to draw a goal symbol somewhere (Think of menus, inline in text, as overlays, etc.), you'd have to fetch the background separately and make sure it's drawn.
Me was a bit boring so I tried to make some design for the goal/rules/environmentobjects.
You can easily change the color by filling the layer named "Color".
I hereby license the following file(s) under the CC-by license
You can easily change the color by filling the layer named "Color".
I hereby license the following file(s) under the CC-by license
Maybe its just the perspective but the goal seems to be placed somewhat asymmetric on the red background.
I find it hard to see. Could we have a less saturated and maybe more bright background?
Anything on red will be pretty hard to make out.
Anything on red will be pretty hard to make out.
You can move the whole object to the right a bit (and maybe remove the shadow - it won't make the big difference during gameplay but can make the whole picture look less distinguishble).
And, btw, backgroung on the first one was brighter :-)
And, btw, backgroung on the first one was brighter :-)
i think sven meant the background, not the object, the background is inly a bit less saturated, but also a bit darker. and as alteredarmor mentioned, the object itself is not centerd that good. if youd remove the shadow, it would fit better imo
Well, the target line is bright so I thought it would be a bad idea to make the background more bright. (bad contrast)
Edit: I've made now an alternative version: a bit brighter, more saturation, drop instead perspective shadow (which unfortunally makes the perspective look weird)
I hereby license the following file(s) under the CC-by license
Edit: I've made now an alternative version: a bit brighter, more saturation, drop instead perspective shadow (which unfortunally makes the perspective look weird)
I hereby license the following file(s) under the CC-by license
Great!
EDIT: Though some aesthetic maniacs can argue that two vertical (which do not look so vertical) bars are not in parallel one to each other (could be an important issue, by the way :-))
EDIT: Though some aesthetic maniacs can argue that two vertical (which do not look so vertical) bars are not in parallel one to each other (could be an important issue, by the way :-))
I still don't like the bright, red background. It works with the black n white image, but any colored image put on the same background will cause trouble. I prefer the second version, actually.
What about dark backgrounds? (inside a cave, for example)
Maybe the final checkpoint should be an animated object (to make it more distinguishable)?
Maybe the final checkpoint should be an animated object (to make it more distinguishable)?
This graphic is only shown in menus, the checkpoints are using particles as graphics.
Oh, I see. Than darker background will probably be better...
So, the best one would be a compilation of background from SECOND image and object placement from THIRD image?
So, the best one would be a compilation of background from SECOND image and object placement from THIRD image?
May an arrow, showing into the goaldirection, could optimize it a bit.
Apropos: Many games display an arrow at the corner of the screen, pointing into the direction of something that lies outside the screen (e.g. a goal). It'd be possible to implement something like this for the parkour too.
That would be nice. Especialy when a scenario requires that all checkpoints are triggered in exact order. Missing one of them is simple enough. The arrow here will be of great help.
There already is a tiny red dot, I just didn't implement any graphics, but that's certainly on the todo.
Oh, so there what it is! (The first time I saw this annoying red dot - thought it was some kind of bug) :-).
Showing the arrow only when the goal is out of view range is not possible at the moment, because you can't know if the goal is in range or not. You'd also need the viewport size/aspect ratio to position the arrow correctly.
>Showing the arrow only when the goal is out of view range
Couldn't one just use some Distance() and PathFree() checks? I suppose this wouldn't work perfectly if a player's view range was changed, though.
The main idea was to draw an arrow at the edge of the screen if your goal lies out of it (the screen). But if the goal lies within the screen this arrow will be somewhat odd.
The problem is that when you change your scale (zoom in or out) your goal will change position from whithin to beyond the screen and vice versa. Calculating the actual placement of (and need for) an arrow can be rather difficult.
The problem is that when you change your scale (zoom in or out) your goal will change position from whithin to beyond the screen and vice versa. Calculating the actual placement of (and need for) an arrow can be rather difficult.
Thats why the arrow should be: not very big, not very contrast and (perhaps) transparent (also to be shown in some distance of the clonk) not to attract much attention.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill