ok maybe I was a bit too strong and brief in what I was saying. I’m actually interested and am trying to be helpful, so let me get back to the original point and go over it in full:
Your challenge may be low key but it’s confusing. Are we or are we not supposed to be looking at every single factor that you’ve listed above? To be entirely clear I mean this list:
As in, in order to even submit something, we should be aiming to better all of these figures?
At first because all you scored was this:
I thought that was all that mattered. But then you said wait, no, we have to consider the economy too, and so that’s what made me look at the first list.
Thing is, that first list is ridiculously long. A ‘low-key’ ‘casual’ challenge shouldn’t have such a long list. So my suggestion, which I’ll now flesh out, is that most of those things should be calculated in the scoring. That is to say, the easiest way is to generate a spreadsheet which automatically calculates the variables and all you need to do is input them and get a nice simple index value at the end.
As it stands you’ve placed a significant onus upon a user who is even contemplating building something for this, before we can even begin, and since most of the requirements appear to be a strict binary yes/no, they also seem very arbitrary. I’ll absolutely acknowledge that it should be easy enough to build an engine that can better each and every one of the stats, but the reason we’re discouraged from even trying is the sheer number of things we have to check every time we make a change on an engine, and trust me, people who actually want to take this on will be doing that more often than you think.
So my suggestion here would be to make most of those factors part of the scoring metric. Things that you don’t think are as important. Attributes that are necessary to keep things to a level playing field should be kept strict, like the octane. It’s also reasonable to place a hard upper limit on PU and engineering time. Dimensions are harder to track without switching back and forward and also you’d be crimping certain engine layouts more than others, and if you’re going to amalgamate specific output and performance index into that, then why don’t you simply go with a more meaningful measurement like a lower and upper limit for displacement?
The other thing you have to watch out for is redundancy in your variables. Some variables will count certain things within their calculation e.g. performance index is an amalgam of peak power and redline, and I see no reason to require that the redline be >7300 unless you want to make it harder to achieve peak reliability and pretty much preclude people from building with low friction pistons. If that’s what’s implied, then it’d be simpler to state that directly. I could go on, but I think I’ve said enough there.
In short, if something was meant to be quick and easy and simple, it should actually be quick and easy and simple, not like trying to open an 8 pin tumbler lock with a hairpin. After all, if you weren’t thinking somebody might want to engage, why did you bother making the thread? You get me?
as that would probably be the most cost effective way… focusing on specific output.
