Hiead wrote:

I'll call you on this one, too. :)

You're not getting the point of Loduwijk's post. A developer might clearly see problems in another game's programming execution without even examining the source code, but the average player is just that, a player, and suprisingly enough, most people on BYOND are just players. They have absolutely no idea of the inner workings of a game... all they see is the end result of it. If the game PLAYS the way they expect(no major bugs), they won't complain.

For example, in my newest game, Project Talon, I use a HTML window system almost identical to, but not as advanced as in Deadly Waters. One good Deadly Waters player complained to me that the windows were "spamming" him(kept refreshing and he couldn't close them). He kept clicking the red X, when in both games the windows distinctly have a "close" link at the bottom of them, and this both stops windows from refreshing data and closes them, or at least allows you to with the X. My "more advanced" HTML window system checks to see if a person has moved away from the console every time it refreshes, and if they moved it closes. Also, it has some windows that don't need to be fed new data constantly have a longer refresh time (10 seconds), so these can simply be closed with the X before that 10 seconds. All that player knew was that in my other game he is not bothered with persistent windows because he knew you can simply walk away from the console instead. He did not stop to think to look for that "close" link that both systems share (but he didn't use in one), or that one system's coding might be different from the other and I had to work harder on one system.

Another example happened the same day, but is much easier to explain. Someone asked me "Oh, you fixed the air supply?(non-important feature that I haven't changed in months but he just noticed that worked now)" I asked "What air supply?(There is an air supply of the entire boat, and a personal one that you can drown if it goes all the way down)" He explained that he just noticed the whole boat's air supply go down slightly when submerged, and I said in the older versions the air supply would go down dramatically if you were submerged and if you couldn't surface everyone would die. I said that it wasn't realistic and those versions were buggy, but he said it sounds like fun. See, the player sees something in gameplay they like, but ignores the fact that the older versions were unrealistic and very buggy.

Hiead wrote:

I'm not arguing that the "prettiness" and "cleanliness" of the code itself is important, but that it actually does it's function, and does it properly, is an important factor. It wouldn't do those functions without the code behind it.

Hiead

Um, what? I argued that players don't care at all about the robustness of your code... they don't even think about the code behind of what they're playing. It doesn't matter if a nuke and a tornado went through your source code, as long as it works as they want to play they won't complain.

That's not what he's saying though. He's saying that if it runs fine (as in it doesn't slow down and it doesn't have bugs everywhere) then the player will never notice the difference between good and sloppy code.
For all a player knows or cares Tekken could track health by using a hundred vars and turning them on/off depending on how much health you have. As long as that's not slowing the game down to the point where the player realises then what difference does it make?

All of them make a game look Good.

Loduwijk wrote:

Hiead wrote:

Justin Knight wrote:

as long as it works

It doesn't do so without the code.

Which makes it a programming issue, not a gameplay issue. And no, "If there's no code there is no game to play in the first place." is not a valid argument, as I could make similar indirect arguments concerning just about anything.

Not necessarily, without icons you still have a game, we call them text-based adventures or more commonly, Multi User Domains. If one does not have a HUD? Then we can make up controls via the keyboard and/or mouse.

Gameplay is a biproduct of code, and the ability of the player to percieve and understand what's happening on screen without any or little frustration. This is mostly a non-issue for guys like me who grew up playing MUDs, Moos, Mucks, etc.

I can't remember what the rest of the list was, but I'm just about positive none of them are logically as important as the code itself.

Whether the code is clean or not is insubstantial as long as it works, but the problem arises in all the little things; speed and efficency being perhaps the largest issue as often it is hard for the new or intermediate programmer to concieve solutions to code problems that don't take a lot of code to solve.

Other factors make the game run slow such as to many icons and such. Not just the coding.

Knifo wrote:

Other factors make the game run slow such as to many icons and such. Not just the coding.

Run-time generated icons will make the game run slow for those with slow connections, but having more icons in the rsc? As far as I know, having a larger rsc does not affect gameplay after the rsc has been completely downloaded.

I think everyone has forgotten the original question!
code and gameplay are important but they do not change the appearance of a game!
the question was "WHAT MAKES A GAME LOOK GOOD?"
the answer is the graphics and only that.
the map and the icons must be of the same style, similar colours. look at any game on the market and the players, npcs and background are in harmony as far as the artistic way that they are drawn. The icons must not look out of place on the map. They must look like they belong where they've been put. any movement of npc's must be logic and coherent and have (or seem to have) a purpose or reason for their deplacements. The rules or all movements should be the same for all or each type on personage.