> One, developers are continually reinveting the wheel.
That is true, but you need to understand why this happens.
It's about over coming techincal issues in an engine to provide a more realistic game. Every game engine is a kludge'd "reality simulator". Even representing color as the popular 3-tuple: red,green,blue is an APPROXIMATION of what happens in the real world, because the only way to get a fast frame rate, is to cheat on the simulator like crazy. As computers get faster, we can do less cheating. Meaning less hacks, to achieve the "proper thing." -- but we still have a LONG ways to go.
Here's a practical example:
In order to provide more visual detail, one could simply up the vertex/poly count for a model. The problem is, this chews up bandwidth, and provides decreasing returns. A clever 'hack' (normal mapping) lets you achieve the same visual look, but FAR cheaper. Simple Bump Mapping Tutorial
Game Engines are constantly being pushed to their limit. When you can no longer shoe-horn a feature in, it is far better to start with a clean slate.
The hard part is designing an engine that is both 1) Fast 2) Flexible
Usually, 3) Cost is involved, so pick which 2 of the 3 you want.
Thus decrying developers keep re-inventing the wheel, is mis-leading. It sweeps all the problems under the rug, instead of looking at all the reasons.
-- Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
Having shipped a few titles, here is what I've noticed...
1. Tecnically Details of implementation On a console, there are numerious technical details (barriers of entry) that need to be worked around. On a 40 man team, usually there is 1 guy dedicated to just rendering, 1 to CD/DVD & movie loading/playback, 1 for physics, 1 for audio (basically core engine), the rest of programmers on the game coding. Memory Mananement is a secondary killer issue to worry about. Now, you just don't sit down one day and decided to write a rendering / sound engine on the PS2. This thing takes weeks to get working, and years to get optimized. Indie teams just don't have the man-power to build "Rome" in 2 years.
2. Art "Good" art costs a LOT. Indie games just don't have to the budget, to compete with game studios. Is it necessary? No, but in today's economy, presentation gets noticed more then form.
3. Marketing If you can't afford the shelf space in Walmart, which accounts for over 80% of the game buying public, chances are, your game is going to be a dud, due to lack of exposure.
The best advice for the indie game devs is "Less is More" -- focus on the _core issues_, namely gameplay. People are more likely to remember a fun game with bad graphics, then a bad game with great graphics.
-- Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
I have mixed opinions, about the dumbing-down as you call it.
I kind of miss the old-thrill of the guild dungeon crawl in UO, when you never knew if the PKers were out. Playing in a "safe" dungeon, where you only have to worry about stategy against the monsters, while is still entertaining, it just doesn't have the same adrenaline flow. But at the same time, I don't miss the lack of griefers, and the ninja looting.
Game design is always a trade-off. The majority has voted that they don't like perma-death. Is that _really_ "dumbing down" the gameplay?? Some just don't find permanent death fun -- I know that I certainlly don't, especially when you die to lag!
So before you start criticising the 'duming down', you may want to clarify what you mean. See my other post on risk/reward.
-- Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
It's nice to see someone else understand the whole "risk/reward" ratio, or "time/reward" ratio of current games.
As you rightly say, the old UO / EQ days of the early MMORPGS's had the whole risk/reward ratio heavily weighted towards time -- I'll say it was idiotic to camp a mob for 4 hours, just to have one item drop -- I got better things to waste my time on. WoW has changed this to be more rewarding with less risk/time required -- at least up to the mid-game. (Allthough travelling still sucks in WoW, due to the designers complete lack of understanding dead time, but I digress.) As MMORPGs continue to get more popular, this shift isn't going to slow down; more and more casual gamers will demand more reward per given time. Older gamers (30+), just don't have the same amount of time to spend, like they once did (20+), meaning I will vote with my dollar with the games that entertain me the most, given the few hours I play a week.
I'll say tastes in gaming have changed. These days, if I can't play a game co-op, I'm usually not interested in playing it. (There are exceptions.) I used to love FPS's: Quake, Team Fortress, BF1942, Call of Duty, Serious Sam. Having checked out Quake 4 and Doom 3, I feel like the whole soul of a fun game is completely lacking.
-- Game Design is about the unholy trinity of: Realism, Logicalness, and Convenience.
Unfortunatly far too many people (especially player) are complaining about the wrong thing.
Except you're ignoring one small detail: Copyright is an _artifical_ right. Furthermore, it was backed by the _publishers_ to prevent other publishers from making a dime.
Why is it such a crime against humanity if I borrow a CD from a friend, copy it so I can listen to it whenever I want without bugging him, and give his original back? In fact, in Canada, a person can do just this -- because taking copyright to its logical conclusions leads to idiotic situtations.
Lastly, I don't seen any lack of progress or art, simply because we didn't have copyright for the last few thousand years.
> For one thing, every division of Sony is clearly at odds with every other division.
When you have the same company in court against _itself_ (distributors of music vs ripping devices vs selling cds to burn), I think that would be the first sign, that there is a bigger problem.
Hey Gary, thx for the stimulating discussion! You've given me some good ideas to think about.
I'm thinking of how to efficently represent and render the worst case -- some canyon wall, which has tons of entrances / crevices.
Initially I was thinking of doing some sort of texutre uv-unwrap, but applied to vertices (so you could have 2 or more values sharing XZ coords), but the cave entrances shot that down.
I guess there are only really two ways to do this...
1) Heightfield + 3D object(s) for each cave entrance. i.e. Morrowind. Since you typically don't have too many entrances all in one place, this is a good solution. The only problem heightfields have is range (or the lack of it I would say), due to being quantized at 8 or 16 bits, meaning mountains are never really "HIGH". (World of Warcraft actually has the first 'valley' that I've been impressed with on the Horde side.) I'm wondering if one could do dynamic ranges, say, each chunk has a base altitude; the only problem I see is the chunk edges and avoiding 'cracks', but certainly doable, since sea-level tends to be 'localized.' i.e. You don't have too many mounatins on the prairies. Heightfields just have far too many advantages to give up -- especially easy texturing, and geo-morphing is easy to do such as ROAM or something similar.
2) Proper 3D Mesh, which isn't _too_ bad; the advantage is the entrances look more "natural." The big problem I see is the CV checks, but isn't this the same problem with case (1) object?
Aside, you still have to page in chunks of the terrain, which isn't complicated. Now, since you are paging in chunks, you could effectively treat each chunk as a heightfield, since that is the majority of the cases -- which has the propery of being fast and easy to render and do collisions on.
Interesting that we could reach a 'common case'. The other neat thing is that the geo-morphing is independent of the terrain representation, which is pretty cool. (Or course you'll want to use continious LOD if using heightfields via bin-trees or quad-trees, etc. or progressive meshes if using 3D models.
I was hoping to hear of a 3rd solution, but I just don't see one.
Thx for the reminder about portals! I see the cases ranging from 0 portals... N portals, but effectively they are really the same thing.
1) One big "Full" 3D Mesh, from terrain to cave insides. But since the terrain needs to be broken up, for the Scene Graph, might as well put a portal between the two terrain ojects, since the cost isn't that expensive.
2) Go portal crazy. Halo, Quake, UT, etc use portals to speed up rendering, so it looks like this is the 'best' solution so far.
Since a big part of render management is about partitioning / caching, portals are a natural way to help support this.
The other real issue is texturing. The simpler it is, the easier it is to work with, and faster the artists can make it look good. The question is, does 'simple' have enough detail?
Guess I should check out how Halo maps are created.
That's true, that the observe-theorize-experiment is a cycle and forms a feed-back look, but without first observing, what would you be theorizing?
Any time we see that pattern, we have a "Science", because we can then formulate rules, on how to do things "better" -- where better may be faster, cheaper, more efficent, etc.
I used to think so at first, but that's not going to happen, because it is un-workable. It is un-workable because Linux supports more and more devices over time. It takes a while for the common API to perculate up.
If we could "freeze" what devices the kernel supported, then I would agree, 'stabalizing' the kernal API would be a great feature, for each of the 2.x series independently. But that is just not going to happen when the _hardware_ itself changes. i.e. new buses (PCI Express), etc.
In fact, there are only 2 reasons I see to upgrade an OS (or parts of it): 1) To support (new) devices 2) Bug-fixes - usually either security, or performance.
> Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
BeOS was the first one to do this back ~ 2000. Each release would get faster (partially due to better compiler support.) But since it was only popular among geeks, I'm not surprised you haven't heard of it.
But yeah, it's nice to that OS X performance is getting better. It allows the user to run more (widgets), etc.
The real problem is when the _same_ thing has _two_ different values.
Blizzard could assign the gold a value of zero, since as you correctly point out -- it is just bits. However, if other players are "trading" it, they are assigning a value to it.
.. when I was taking Operating Systems II, and our first homework questions was to decrypt the encrypted assignment once we wrote a public-private de/encryption program, using the public & private keys we were given. Shortly after I got my program written & debugged, I figured out that the teacher had used/given out a wrong number (!), meaning the assignment couldn't be decoded, so I told my buddy who was also in the same class with me before the weekend so he didn't have to waste his time as well.
The following week in class the teacher announces the correct public & private keys, and most of the class flipped out since they had spent the time trying to figure out why their program wasn't decoding the encrypted assignment. (I guess those students never used a test case to verify that their program _actually_ was working correctly!?)
I guess it pays to pay attention to the expected data.;-)
Man, where you 5 years ago, when I needed this wisdom?!
This has been a painful lesson for me to learn. Learning to set priorities (time frames) on everything you do, has had the opposite effect that being structured would lead you believe. Being more structured has given me more freedom!
It's like learning that you can work on developing your creativity. Illogical, but it works!
I wonder how many programmers suffer from procrastination?
-- I wasn't bright enough to be a (pure) Mathematician, and I was too lazy to be an Engineer, so I became a programmer!:-)
Re:Some artists just want to be heard...
on
CRIA Falling Apart?
·
· Score: 1
I wonder how many other programmers / geeks are into:
Slashdot Mirror
> One, developers are continually reinveting the wheel.
That is true, but you need to understand why this happens.
It's about over coming techincal issues in an engine to provide a more realistic game.
Every game engine is a kludge'd "reality simulator". Even representing color as the popular 3-tuple: red,green,blue is an APPROXIMATION of what happens in the real world, because the only way to get a fast frame rate, is to cheat on the simulator like crazy. As computers get faster, we can do less cheating. Meaning less hacks, to achieve the "proper thing." -- but we still have a LONG ways to go.
Here's a practical example:
In order to provide more visual detail, one could simply up the vertex/poly count for a model. The problem is, this chews up bandwidth, and provides decreasing returns. A clever 'hack' (normal mapping) lets you achieve the same visual look, but FAR cheaper.
Simple Bump Mapping Tutorial
Game Engines are constantly being pushed to their limit. When you can no longer shoe-horn a feature in, it is far better to start with a clean slate.
The hard part is designing an engine that is both
1) Fast
2) Flexible
Usually, 3) Cost is involved, so pick which 2 of the 3 you want.
Thus decrying developers keep re-inventing the wheel, is mis-leading. It sweeps all the problems under the rug, instead of looking at all the reasons.
--
Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience
Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
Having shipped a few titles, here is what I've noticed...
1. Tecnically Details of implementation
On a console, there are numerious technical details (barriers of entry) that need to be worked around.
On a 40 man team, usually there is 1 guy dedicated to just rendering, 1 to CD/DVD & movie loading/playback, 1 for physics, 1 for audio (basically core engine), the rest of programmers on the game coding. Memory Mananement is a secondary killer issue to worry about. Now, you just don't sit down one day and decided to write a rendering / sound engine on the PS2. This thing takes weeks to get working, and years to get optimized. Indie teams just don't have the man-power to build "Rome" in 2 years.
2. Art
"Good" art costs a LOT. Indie games just don't have to the budget, to compete with game studios. Is it necessary? No, but in today's economy, presentation gets noticed more then form.
3. Marketing
If you can't afford the shelf space in Walmart, which accounts for over 80% of the game buying public, chances are, your game is going to be a dud, due to lack of exposure.
The best advice for the indie game devs is "Less is More" -- focus on the _core issues_, namely gameplay. People are more likely to remember a fun game with bad graphics, then a bad game with great graphics.
--
Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience
Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
I have mixed opinions, about the dumbing-down as you call it.
I kind of miss the old-thrill of the guild dungeon crawl in UO, when you never knew if the PKers were out. Playing in a "safe" dungeon, where you only have to worry about stategy against the monsters, while is still entertaining, it just doesn't have the same adrenaline flow. But at the same time, I don't miss the lack of griefers, and the ninja looting.
Game design is always a trade-off. The majority has voted that they don't like perma-death. Is that _really_ "dumbing down" the gameplay?? Some just don't find permanent death fun -- I know that I certainlly don't, especially when you die to lag!
So before you start criticising the 'duming down', you may want to clarify what you mean. See my other post on risk/reward.
--
Game Design is about the unholy trinity: Realism, Logicalness/Consistency, Convenience
Unfortunately, far too mamy players are argueing about the wrong thing, usually the red herring of realism.
It's nice to see someone else understand the whole "risk/reward" ratio, or "time/reward" ratio of current games.
As you rightly say, the old UO / EQ days of the early MMORPGS's had the whole risk/reward ratio heavily weighted towards time -- I'll say it was idiotic to camp a mob for 4 hours, just to have one item drop -- I got better things to waste my time on. WoW has changed this to be more rewarding with less risk/time required -- at least up to the mid-game. (Allthough travelling still sucks in WoW, due to the designers complete lack of understanding dead time, but I digress.) As MMORPGs continue to get more popular, this shift isn't going to slow down; more and more casual gamers will demand more reward per given time. Older gamers (30+), just don't have the same amount of time to spend, like they once did (20+), meaning I will vote with my dollar with the games that entertain me the most, given the few hours I play a week.
I'll say tastes in gaming have changed. These days, if I can't play a game co-op, I'm usually not interested in playing it. (There are exceptions.) I used to love FPS's: Quake, Team Fortress, BF1942, Call of Duty, Serious Sam. Having checked out Quake 4 and Doom 3, I feel like the whole soul of a fun game is completely lacking.
--
Game Design is about the unholy trinity of: Realism, Logicalness, and Convenience.
Unfortunatly far too many people (especially player) are complaining about the wrong thing.
Except you're ignoring one small detail: Copyright is an _artifical_ right. Furthermore, it was backed by the _publishers_ to prevent other publishers from making a dime.
Why is it such a crime against humanity if I borrow a CD from a friend, copy it so I can listen to it whenever I want without bugging him, and give his original back? In fact, in Canada, a person can do just this -- because taking copyright to its logical conclusions leads to idiotic situtations.
Lastly, I don't seen any lack of progress or art, simply because we didn't have copyright for the last few thousand years.
Which lens were you referring to, with the 100,000 actuations?
= productlist&A=details&Q=&sku=234444&is=USA&addedTr oughType=categoryNavigation
Thx for the infon the lens. Been looking to upgrade...
http://www.bhphotovideo.com/bnh/controller/home?O
> For one thing, every division of Sony is clearly at odds with every other division.
When you have the same company in court against _itself_ (distributors of music vs ripping devices vs selling cds to burn), I think that would be the first sign, that there is a bigger problem.
Hey Gary, thx for the stimulating discussion! You've given me some good ideas to think about.
... N portals, but effectively they are really the same thing.
I'm thinking of how to efficently represent and render the worst case -- some canyon wall, which has tons of entrances / crevices.
Initially I was thinking of doing some sort of texutre uv-unwrap, but applied to vertices (so you could have 2 or more values sharing XZ coords), but the cave entrances shot that down.
I guess there are only really two ways to do this...
1) Heightfield + 3D object(s) for each cave entrance. i.e. Morrowind. Since you typically don't have too many entrances all in one place, this is a good solution. The only problem heightfields have is range (or the lack of it I would say), due to being quantized at 8 or 16 bits, meaning mountains are never really "HIGH". (World of Warcraft actually has the first 'valley' that I've been impressed with on the Horde side.) I'm wondering if one could do dynamic ranges, say, each chunk has a base altitude; the only problem I see is the chunk edges and avoiding 'cracks', but certainly doable, since sea-level tends to be 'localized.' i.e. You don't have too many mounatins on the prairies. Heightfields just have far too many advantages to give up -- especially easy texturing, and geo-morphing is easy to do such as ROAM or something similar.
2) Proper 3D Mesh, which isn't _too_ bad; the advantage is the entrances look more "natural." The big problem I see is the CV checks, but isn't this the same problem with case (1) object?
Aside, you still have to page in chunks of the terrain, which isn't complicated. Now, since you are paging in chunks, you could effectively treat each chunk as a heightfield, since that is the majority of the cases -- which has the propery of being fast and easy to render and do collisions on.
Interesting that we could reach a 'common case'. The other neat thing is that the geo-morphing is independent of the terrain representation, which is pretty cool. (Or course you'll want to use continious LOD if using heightfields via bin-trees or quad-trees, etc. or progressive meshes if using 3D models.
I was hoping to hear of a 3rd solution, but I just don't see one.
Thx for the reminder about portals! I see the cases ranging from 0 portals
1) One big "Full" 3D Mesh, from terrain to cave insides. But since the terrain needs to be broken up, for the Scene Graph, might as well put a portal between the two terrain ojects, since the cost isn't that expensive.
2) Go portal crazy. Halo, Quake, UT, etc use portals to speed up rendering, so it looks like this is the 'best' solution so far.
Since a big part of render management is about partitioning / caching, portals are a natural way to help support this.
The other real issue is texturing. The simpler it is, the easier it is to work with, and faster the artists can make it look good. The question is, does 'simple' have enough detail?
Guess I should check out how Halo maps are created.
All good stuff to think about...
Cheers
Thx for the info on Halo (1) texturing!
Anyone know of good approximiations or solutions to the 'over-hanging cave entrance' problem?
That's true, that the observe-theorize-experiment is a cycle and forms a feed-back look, but without first observing, what would you be theorizing?
Any time we see that pattern, we have a "Science", because we can then formulate rules, on how to do things "better" -- where better may be faster, cheaper, more efficent, etc.
That's an interesting comment, of the Top-Down and Bottom-Up approach.
Basicaly, Andy 'proved' this theory correct, by building an OS. (Top-Down)
Linux learnt the theory, by doing the implementation. (Bottom-Up.)
Theory ALWAYS comes after Experience/Expirementation. That is, if you couldn't observe it, how did you come up with the theory for it?!
I used to think so at first, but that's not going to happen, because it is un-workable. It is un-workable because Linux supports more and more devices over time. It takes a while for the common API to perculate up.
If we could "freeze" what devices the kernel supported, then I would agree, 'stabalizing' the kernal API would be a great feature, for each of the 2.x series independently. But that is just not going to happen when the _hardware_ itself changes. i.e. new buses (PCI Express), etc.
In fact, there are only 2 reasons I see to upgrade an OS (or parts of it):
1) To support (new) devices
2) Bug-fixes - usually either security, or performance.
Cheers
> Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
BeOS was the first one to do this back ~ 2000. Each release would get faster (partially due to better compiler support.) But since it was only popular among geeks, I'm not surprised you haven't heard of it.
But yeah, it's nice to that OS X performance is getting better. It allows the user to run more (widgets), etc.
Mod up -- because this is very good point!
The real problem is when the _same_ thing has _two_ different values.
Blizzard could assign the gold a value of zero, since as you correctly point out -- it is just bits.
However, if other players are "trading" it, they are assigning a value to it.
Now which value does it have??
To sumarize, the Risk/Reward ratio is completely out of whack in MMORPG.
It doesn't have to be, but sadly that is the way it is.
If they constantly aren't constant, does that make them constant? ;-)
--
Constants aren't.
Variables are.
- Murphy's (Computer) Law
.. when I was taking Operating Systems II, and our first homework questions was to decrypt the encrypted assignment once we wrote a public-private de/encryption program, using the public & private keys we were given. Shortly after I got my program written & debugged, I figured out that the teacher had used/given out a wrong number (!), meaning the assignment couldn't be decoded, so I told my buddy who was also in the same class with me before the weekend so he didn't have to waste his time as well.
;-)
The following week in class the teacher announces the correct public & private keys, and most of the class flipped out since they had spent the time trying to figure out why their program wasn't decoding the encrypted assignment. (I guess those students never used a test case to verify that their program _actually_ was working correctly!?)
I guess it pays to pay attention to the expected data.
Try the "classics" ..
Ico
Loom
Monkey Island
Ultima 7
Tetris
Star Control II
Grim Fandango
System Shock
Exactly!
That idiot called (Mr. Eber) should play like Ico.
If a game moves me to emotion, then it is art!
Man, where you 5 years ago, when I needed this wisdom?!
:-)
This has been a painful lesson for me to learn. Learning to set priorities (time frames) on everything you do, has had the opposite effect that being structured would lead you believe. Being more structured has given me more freedom!
It's like learning that you can work on developing your creativity. Illogical, but it works!
I wonder how many programmers suffer from procrastination?
--
I wasn't bright enough to be a (pure) Mathematician,
and I was too lazy to be an Engineer,
so I became a programmer!
I wonder how many other programmers / geeks are into:
* Music
* Martial Arts
* ??
Cheers
It's ok for older people to play cards, board games, or slots?
But not ok to play video games because it is a different medium?
--
Far too many gamers fall victim to the red herring of game realism, when they are really complaining about lack of consistency.
Nice list of top 5!
;-)
Digressing slightly, did you know they left the debugging info in Moo2!
Fire up Borland 3.1 and see all the variable & function names
Since obviously most the reply here don't have a fucking clue what "crunch time" is, let me explain it:
* Working 60-80 hours.
* Crashing at the office.
* On call, 24 hrs
"Cruch Time" at Mickey D's is a joke compared to what the game industry goes through.
http://www.supremelaw.org/sls/31answers.htm
--
A fine is a tax you pay for doing wrong and a tax is a fine you pay for doing all right.