I think the main point is this:

Spending time to improve things becomes meaningless if it doesn't:

a. finish your game faster so that you can have it released sooner therefore creating more potential to gain more players at a quicker rate, or sooner than later
b. make your game more complete so that it can be released therefore creating any potential at all to gain players in the first place
c. make your game work so that it is even playable by potential players

Optimization importance completely changes when the game has more than a handful of players...

In the case of WoW for example, their business plan was setup to work around hundreds of thousands of players, so in their case:

Spending time improving anything is meaningless unless it:

a. decreases the processing time spent in any given procedure depending on the number of calls made for that procedure
b. decreases the total amount of bandwidth in use
c. allows the game to operate longer, more stable, or more efficiently in any way possible
In response to Kaiochao
Kaiochao wrote:
It may be pointless, but it's still technically better.

This, basically. And once you learn the better method you aren't going to forget it (Unless you have altzeimers(sp)), and ultimately you will be a better programmer for sitting down a taking the time to practice good habits.
In response to FIREking
FIREking wrote:
I think the main point is this:

Spending time to improve things becomes meaningless if

if nothing.

Sit and read that. Sit and read that line repeatedly and feel bad about it.

If I see an opportunity to make my project run faster, play better, whatever. I'll take it.

I'm not a lazy slacker that can't be bothered with the menial tasks of my programming just because I want to add the next feature asap because my game's ALL ABOUT PLAYERCOUNT AND NOT ABOUT QUALITY.

No actually that has legitimately pissed me off now.

How the shit can people just say "X REASON IS WHY I SHOULDN'T MAKE MY GAME BETTER"

What the hell.
In response to Rushnut
Lol, here's why: If you never release your game, then it doesn't exist to any players at all. Forever optimizing code will mean your game still does not exist to those potential players, and therefore you are following a development pipeline that never ends hence development becomes pointless.

From here, you get into release strategies such as Minecraft's which was, release early, update often. Your concept of "improve everything everytime" works in that release strategy because the game exists to potential players.
Jonathan Blow sums it up best here.
In response to FIREking
I'm not working on a game, so I'll spend this time doing research and experiments to use optimized code initially and habitually for when I do actually work on something.
In response to FIREking
You can consistently and repetedly improve your ability to program to the point that such menial tasks won't have to be done in the first place.

To give it an extreme view so you might understand better, if I were literally perfect at programming, I wouldn't have to optimize anything ever because I'd always do the best thing available at any given moment.

That's obviously not going to happen any time soon but if you sit at it bettering yourself when you see that you can better yourself, i.e when someone posts a better snippet than yours that works the same but runs faster, you'll slowly get better and better.

I'm not saying write a proc, then sit there and nit pick it for the next few hours. I'm saying write something to the best of your abilities and if you learn a better way of doing it, then the best of your abilities gets better and you should use that new skill.

In response to Kaiochao
You'd get a better game out of say ... researching mixing game mechanics together, if "when I do" is a game, which on BYOND I assume it would be.
In response to Rushnut
Actually, even as a 'perfect programmer', you will need to optimise after the fact. Because the main cause of performance issue is changing or mis-understood requirement. The use-case will change and your previously perfect code is now not fit for purpose.

Programming is very logical, the domain it's mapping onto is not.
In response to Stephen001
Stephen001 wrote:
Actually, even as a perfect programmer, you will need to optimise after the fact. Because the main cause of performance issue is changing or mis-understood requirement. The use-case will change and your previously perfect code is now not fit for purpose.

You can't foresee the future, that's a stupid point to try and make.

As a perfect programmer you will do what is the best possible route at any given time.
In response to Rushnut
Pre-optimization for the sake of pre-optimization is one thing

Arguing semantics for the sake of arguing semantics is on a whole different level of retarded.
Right, but my point is exactly that. 'I wouldn't have to optimize anything ever' cannot hold, even as a perfect programmer.

A far better skill, would be the one that decides whether or not it's worth it to spend the time bothering to put that effort in, considering your objectives. As a game developer, your primary objective is making (and releasing) a game that people will play. Bugs cost your player's perception much more than a few milliseconds here or there. Your time (or time to market) is also worth more than those milliseconds. Most goals in fact, are worth more than those milliseconds.

You'd make a far better game by spending this time playing with game mechanics, experimenting with things you'd make a game out of. Also wets your game designer appetite, so ... well, the day you actually make a game is more likely to come.

As my computation complexity professor (somewhat humorously) said once, "If a tree falls in the forest, and no-one is around to see it, who cares?".
In response to Magnum2k
Magnum2k wrote:
Jonathan Blow sums it up best here.

Incidentally, this is very good, so far.
I wrote a similar thing in C++ not too long ago:
std::vector<std::string> Helper::Explode(char separator, std::string str) {

std::vector<std::string> ReturnVector;

std::string curstring = "";
for(int i = 0; i < str.size(); i++) {

if(str[i] != separator) { // if the character selected is not a separator
curstring += str[i];
if(i == str.size() - 1) // last loop
ReturnVector.push_back(curstring);
}
else { // if it is a separator, add curstring to vector and move on
ReturnVector.push_back(curstring);
curstring = "";
}
}
return ReturnVector;
}


It's probably extremely terrible, but it works.
In response to Stephen001
Stephen001 wrote:
As my computation complexity professor (somewhat humorously) said once, "If a tree falls in the forest, and no-one is around to see it, who cares?".

Sums it up.

In response to Kaiochao
Kaiochao wrote:
I'm not working on a game, so I'll spend this time doing research and experiments to use optimized code initially and habitually for when I do actually work on something.

This exactly sums up BYOND's worst problem. We've got some super-talented people, who have the ability and desire to massage code into near-perfection, yet none of them ever use their talents for Good.

BYOND needs great games. But it's really hard to get any great games on here when the people who are most qualified to create great games seemingly refuse to do so. Preferring to spend (waste?) their time on writing and re-writing snippets to optimize things that ultimately don't need optimizing in the grand scheme of things.

People need to stop diving into DM to figure out how to write the most efficient code for dozens of meaningless functions, and MAKE A GAME.
Page: 1 2 3