ID:152497
 
After all, what is the thing that most matters in game?!?

VOTE!
Multiple choice allowed. ;)

  • The code.
  • The icons.
  • The map.
  • The gameplay.
  • The HUD.

    Yeah. I love to see people's opinions. get used to my Voting stuff. o_O

    #Gooseheaded#
Gameplay is always numero uno, and solid code should go without saying. After that, it's up to the creator, but I'd rank graphics (HUD included) lower than the environment planning, the map. Even the best icons and graphical glitz will pale if they aren't utilized creatively and with gameplay in mind.

~X
In response to Xooxer
Its quite obvious what makes a game look good.

Seeing me in the players list. =)
In response to Silent Sage
Gameplay
I think interacting with the map. A lot of RPGs on BYOND don't have things to do ith the map. Boulders falling over a path, or a volcano randomly exploding every now and then. Natural Hazards. Or, Climbing up a cliff wall or sliding down a muddy hill.

The Map
Another thing is how the map is layed out? Ss it just the same area time after time? Or does it have a look and feel that you can tell where you are by looking at that area like in most console games? I've been trying to perfect this with my year long project so far. And wow, Its a doo-zie.
Nintendo offical seal of quality.
Gooseheaded wrote:
  • The code.
  • The icons.
  • The map.
  • The gameplay.
  • The HUD.

  • In my opinion, #1 and #4 are most important. #3 must follow #4 and must fit the theme of the game. #5 and #2 are helpful, but as long as the game is fun and the controls are comprehensive, having bad icons or no HUD won't matter as much.


    --Vito
In response to Elation
Elation wrote:
Nintendo offical seal of quality.

Those are hard to get.
Gooseheaded wrote:
After all, what is the thing that most matters in game?!?

VOTE!
Multiple choice allowed. ;)

  • The code.
  • The icons.
  • The map.
  • The gameplay.
  • The HUD.

  • I'd go with gameplay first. You could have the most beautiful, artistic game in the world and it wouldn't count a dime if every action was prompted with an alert box. And unprofessionalism in games, such as mispellings, "IM speak," etc., is a real turn-off.

    After gameplay, I'd say programming is the next up. Good, solid systems tend to complement the gameplay aspect, and provide a nice experience to the end-user. Besides that, errors are never fun to deal with.

    Third up would be the map. A nice, well-detailed map that can provide for interesting twists and turns during play can keep players entertained on nothing but travelling alone for quite some time.

    After the map, graphics can help. Good graphics don't necessary have to have some "realism" to them, but they should fit the theme. Scream of the Stickster obviously doesn't have the best graphics(erm, stick figures...), but the gameplay is solid enough and the graphics fit the theme of the game so well that the game is still very entertaining.

    The HUD, while important, is last in my order. As long as the HUD helps more than it hurts, or provides more to a player's experience than it takes away, the HUD is fine. The HUD should be something that, rather than trying to look pretty and whatnot, is "invisible" to the player while still being helpful. Basically, a player should get what the HUD gives without having to actually notice that there's a HUD that's taking up part of their screen.

    Hiead
Gooseheaded wrote:
Yeah. I love to see people's opinions. get used to my Voting stuff. o_O

No. I won't stand for poll-of-the-day/week/month crap. If you want to produce a regular feature, get yourself a member blog and post there, or some other Web page of your own choosing. We don't need these kinds of junk posts cluttering the forums.

Anyway, this post is kind of cockeyed from the beginning, since your subject line and the actual content are at odds (are you looking for what makes a game good, or look good?). Also, as Xooxer deftly pointed out, gameplay is an absolute must and good code must follow. There is simply no contest.

Lummox JR
I don't understand what everyone else is getting at, as the code does not matter at all, not the least bit, where this specific topic is concerned. As long as the game works, works well and relatively bugless, then the player should have no idea at all whether the code is a masterpiece or a spaghetti-bomb.

Crap code can still produce the same results as top-notch code. It just can't be upgraded, doesn't get a bug-fix if you do happen to find a bug, might eat into your CPU more, and might take more memory. None of which have anything to do with the the game looking good or being fun to play.

Code matters - just not to the player. Therefor, it should not even be on that list you made.
To me, It's gameplay, Icons, and Code. Code ties for second place with icons.

The "Fun Factor" in the gameplay can make up for bugs and problems in code (Depending on the size of the bugs and problems). The same goes for the gameplay and icons.

Now why do I say icons are an important factor?

Example: Acheron's Awakening.

The game seems like it will be fun to play, however... those bug-eyed mob icons... They give me a headache. I am not going to play a game that gives me a headache unless it's fun, which I have yet to determine since the game hasn't been released yet.

----

In most BYOND games I've seen with HUDs, the HUDs serve very little function and are there for cosmetic reasons. However, There is no doubt that there are BYOND games where the HUD is vital to the game.

That makes it somewhat difficult to rate the HUD, but since you're asking what makes a game good... HUDs are not essential to create a good game, so it is at the bottom of my list.
Gameplay, icons and map. And no lag! xD
In response to Loduwijk
I'm going to call you out on that one.

Code can make a huge difference. If your game is like any of mine, a lot of the graphical appeal is generated BY the game on runtime. I use a lot of tweaks to make things look more natural in my game. For instance, I generate a lot of icons for clothing, etc. by butchering up a finished product, reducing the colors to a placeholder color, and taking it for a walk through a few procedures, and splice it together.

I even put pixel offsets on trees, rocks, items, etc. just so that they appear to be more random, and not sitting on some grid.

I also make ten different grass icons with different noise patterns on them, do you think I place them by hand? No, I have a program that does it for me, then exports a .dmp file from it.

Yes, these are special cases, yes, these are all graphical extentions, but doing them without a massive download or a cluttered object tree would simply be tedious.

Yes, a lot of these things are totally overlooked by the player, but don't you dare tell me they don't look good, and don't you dare even tell me players aren't scared away by the 50meg rsc download, the lag caused by multiple people queueing up to download.

Code makes ALL the difference in the world, and yes, it can be messy, or it can be efficient, but that's not everything you can do with DM. You can't lump this category out.
You have to have a good map, otherwise the game is boring. GAme play is important as well.
In response to Ter13
But you're not really disagreeing with me. We're talking about what makes a game good, not what makes it easier to program or what's better programming practice.

I'm not saying you can't program smart to make things dynamic and ease your load; but, from the players' perspective, everything you mentioned there is in the graphics department, not code. Therefor, where this thread's topic is concerned, you were talking about graphics, even if it's all just a bunch of code to you the programmer.
In my opinion:

1. Gameplay:
If the game sucks, there's no point in playing it, regardless of anything else.

2. The Map:
I find that even beautifully made games with boring worlds aren't much fun. That is, of course, assuming that the game actually uses a map, such as an RPG/Adventure game of some kind. If the world is boring to explore, it has a large effect on gameplay. So a boring world makes for boring gameplay. Maps that are detailed and interesting can go a long way in captivating players. I mean, I had people playing Ensya for weeks, and there wasn't even anything to do! But the maps were really nice.

3. The HUD:
A game has to have a good user interface. I'm not sure what you mean by HUD, but I'm assuming this has something to do with the controls. I think of Master of Orion III when I think of this - very detailed and complex game, but the user interface was so unwieldlyl that nobody wanted to play it. However, a game that has great gameplay, beautiful maps, and a sloppy HUD will still be played, as long as the HUD isn't too bad.

4. The Icons:
Icons aren't really that important, as long as they get the theme across. I don't really care for ascii characters, but even poorly drawn icons can give the game a unique feel. Better icons are better, but they don't really effect how much enjoyment people get out of the game.

5. The Code:
No one gives a hoot about the code. If the game runs and doesn't cause trouble, its all well and good.


However, in answer to your topic, better graphics are what make a game look good.
In response to Loduwijk
But it's all generated dynamically by code. Therefore, has to do with code. That's my argument.
In response to Mechanios
Wow. I've never thought about that 'random nature' stuff.
I think you're right, it kinda adds some life to the game... Nice detail!!
In response to Loduwijk
I'll call you on this one, too. :)

Loduwijk wrote:
As long as the game works, works well and relatively bugless, then the player should have no idea at all whether the code is a masterpiece or a spaghetti-bomb.

Ah, but this is where you're wrong. The code may be sloppy, but still shouldn't be "weak" and horribly inefficient. Why?

might eat into your CPU more, and might take more memory.

There's a good one. One of the things that make Sword of the Stars fun to play is that it takes little CPU, and little enough memory to allow me to sit and play online with someone(Jon88, heh), while sitting on such programs as wiz_chat and the like. Not a lot of 3D games(especially online multiplayer ones) can keep my memory and resources in check enough to handle the fact that BYOND, Firefox and other programs may be eating from said resource reserves.

None of which have anything to do with the the game looking good or being fun to play.

Sure they do. As well, if a game sat there and ate up my CPU so that it ran horridly slow, or took up enough memory that it crashed every time I tried to run it, it wouldn't be much fun to sit and play, right? Poor response times can really take from the overall presentation of any program.

Hiead
In response to Foomer
Foomer wrote:
5. The Code:
No one gives a hoot about the code. If the game runs and doesn't cause trouble

That's exactly what the code is for, and how it makes the game look good! The goal is for the code to not cause any kind of trouble; be it because the developer decided to use some insane loop where he or she could've divided, or because all of the vital systems are so horribly programmed that the game is too hard to cope with.

Without gameplay, the code isn't worth much. But it certainly comes right after gameplay as the second largest factor! I mean, a certain type of sweet game might not even require a map, nor a HUD. Even so, the players will undoubtedly be judging the game on how smoothly the map and HUD interact with the player(s). This interaction falls down to the code itself; if there is horrible interaction, the players will surely feel negatively about it. And really, a HUD is basically just art and programming. Sure, a pretty HUD is nice, but unless you're just looking for a picture frame around the screen, the HUD is fully dependant on the programming behind it.

Hiead
Page: 1 2