| 1 |
Sorry; I guess the aggressive comment with only a vague explanation was not really constructive.
|
1 |
Sorry; I guess the aggressive comment with only a vague explanation was not really constructive.
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Forb, the "low quality" was about the features as wholes. The models are outstanding but a lot of the defs are crap. Looking nice is of no use if they have a bad effect on gameplay:
|
3 |
Forb, the "low quality" was about the features as wholes. The models are outstanding but a lot of the defs are crap. Looking nice is of no use if they have a bad effect on gameplay:
|
| 4 |
* the hitboxes are usually insanely large. This makes some units not fire, units/projectiles collide seemingly with air, and pathing looks off.
|
4 |
* the hitboxes are usually insanely large. This makes some units not fire, units/projectiles collide seemingly with air, and pathing looks off.
|
| 5 |
* the resource values are inconsistent. It's good for gameplay if there is standarized visual feedback (eg. "that thing gives no metal because it's a plant, this one does because it's a rock, and that other rock gives more because it's larger") because people can now make decisions efficiently without having to check everything first. Then there are things like cons automatically attempting to reclaim 0-worth stuff which wastes huge amounts of time.
|
5 |
* the resource values are inconsistent. It's good for gameplay if there is standarized visual feedback (eg. "that thing gives no metal because it's a plant, this one does because it's a rock, and that other rock gives more because it's larger") because people can now make decisions efficiently without having to check everything first. Then there are things like cons automatically attempting to reclaim 0-worth stuff which wastes huge amounts of time.
|
| 6 |
* minor things which aren't as important but still contribute to quality. For example health values (some trees are tankier than rocks), footprint (some things have tiny footprint but are actually wide enough for the model to clip), lily pads that sink, and especially names because these are the most visible to the user.
|
6 |
* minor things which aren't as important but still contribute to quality. For example health values (some trees are tankier than rocks), footprint (some things have tiny footprint but are actually wide enough for the model to clip), lily pads that sink, and especially names because these are the most visible to the user.
|
| 7 |
\n
|
7 |
\n
|
| 8 |
Examples
of
gameplay
defs
which
ruin
otherwise
beautiful
models:
|
8 |
Examples
of
defs
which
ruin
otherwise
beautiful
models:
|
| 9 |
[spoiler]
|
9 |
[spoiler]
|
| 10 |
[img]http://i.imgur.com/pNza9LB.png[/img][img]http://i.imgur.com/lcCL2JH.png[/img]
|
10 |
[img]http://i.imgur.com/pNza9LB.png[/img][img]http://i.imgur.com/lcCL2JH.png[/img]
|
| 11 |
[/spoiler]
|
11 |
[/spoiler]
|
| 12 |
\n
|
12 |
\n
|
| 13 |
Obviously mappers can fix that themselves by replacing the defs but nobody actually does that. I'd support a version which is just a model base because then people would be forced to make sensible defs, but since the whole point of the library is to make adding features as easy as possible (especially for people who don't know how to work with the defs!) it's probably out of question.
|
13 |
Obviously mappers can fix that themselves by replacing the defs but nobody actually does that. I'd support a version which is just a model base because then people would be forced to make sensible defs, but since the whole point of the library is to make adding features as easy as possible (especially for people who don't know how to work with the defs!) it's probably out of question.
|
| 14 |
\n
|
14 |
\n
|
| 15 |
The other solution would be to fix all the features inside SF. This is not really possible because SF is a inter-game library but each game can have different expectations from the same model. For example setting default resource values to 0 breaks the de facto ZK standard of having rocks/trees provide M/E.
|
15 |
The other solution would be to fix all the features inside SF. This is not really possible because SF is a inter-game library but each game can have different expectations from the same model. For example setting default resource values to 0 breaks the de facto ZK standard of having rocks/trees provide M/E.
|
| 16 |
\n
|
16 |
\n
|
| 17 |
Not being compatible with ZK infra is not SF's fault but nevertheless it is still a valid point which further discourages usage for ZK.
|
17 |
Not being compatible with ZK infra is not SF's fault but nevertheless it is still a valid point which further discourages usage for ZK.
|
Map Battle for Planet XIV - v03