I find it interesting that most posts on this thread are talking about video game programming, not video game design. Once upon a time, back when 8-bit processors and 16-color displays were king, one or two people could design and program a game, and probably do the artwork and sound as well. These days, game studios tend to have a small number of designers and plenty of programmers, artists, and Quality Assurance personnel. The article doesn't actually mention programming -- it mentions that the curriculum has courses on game design, and special effects, and has a creative writing requirement.
The whole concept of a college course that teaches game design is amusing, considering that the job title "designer" has half a dozen different meanings. A game designer can be anything from a story writer to a world builder to a game system designer. Some designers use scripting languages and actually do implementation, while most don't. Design-related positions tend to pay less than programming, but more than Quality Assurance or Tech Support. It's also worth noting that designer job security isn't all that great, either. However, you're much more likely to land a world builder job by creating an impressive mod or map for an existing game than by waving a degree around.
If you want to get into video games, then go the programming route. It pays better and there are many more positions available. You get to work very closely with the designers and have some influence in the design of the game itself. Job security is better -- and, you still get to fire up the latest games at work and play them while calling it research!
"Massively Multiplayer" is a bit of a misnomer, in my opinion. NO game today actually allows you to participate with other players en masse. At best, you might interact with dozens of other players at once, but in the current crop of "massive" online games all that means is a big lag fest. You get that many players together and one or both of the following happen: Your 3D card chokes on all the polys and your framerate drops; or your bandwidth can't handle simultaneous updates from all the other players on your screen.
What does it matter if several hundred thousand people play the same game? Only about 10% of them will be logged on at any given time. Only 5% of *those* will be on the same server as you. And of the ones actually logged in, you'll only be able to play with less than 1% of them at a time.
I predict that within the next 10 years we will see games that can rightfully claim to be "massively" multiplayer. These games will have millions of simultaneous players, all sharing one huge game world (instead of dozens of copies of one). Line of sight restrictions won't exist as such -- there won't be any fog keeping you from standing on top of a mountain looking down on a city and being able to make out hundreds of players milling about, all in high resolution breathtakingly clear rendered 3D and in glorious real time.
I can picture a massive starship battle, in fully 3D: There are two sides involved, and each armada has thousands of ships. At the helm of each individual ship is a player much like yourself. You are somewhere in the middle of your side's armada, so you can see hundreds of friendly ships flying in a loose formation toward the cloud of approaching enemies. Your mini-map has a dot for each ship in your fleet and each enemy in sensor range. You tense for battle, then the two fleets collide. The destruction at the leading edge is massive, but it takes practically no time for both fleets to occupy the same space.
At first your only thought is to avoid a head-on collision, but reflexively you start blasting away with your foreward cannons as you begin to dodge. Dozens of explosions dot the spacescape around your ship. Cannon and laser fire arc around between tiny dots you know to be fairly distant ships. You narrowly miss an oncoming enemy and as you bank around you are treated to a glorious explosion as one of your comrades is obliterated. Too bad for him -- but also too bad for the hostile flying cockily through the debris. You're quicker than he is and your cannons shred his ship before he even sees you.
Now that the initial charge is over, the pace slows a bit. Allies group together for the strength of numbers, flying slowly for more maneuverability, surveying the part of the battle nearby to determine where they can deal the most damage...
Something like that could never happen with today's hardware and bandwidth limitations. In ten years? It'd probably be a piece of cake.
Ahh, MOO. This article has given me attacks of nostalgia. I first started writing code in MOO nearly a decade ago. One of the more fun things I did was to code up an interesting object called a Port-O-Potty. It was bigger on the inside than it was on the outside, with an entryway, party room, and men's and women's toilets. (That's just surrealism allowed by clever use of containment and room linking -- not code.) But the fun part was, it would teleport itself around the MOO randomly every few minutes. Port-O-Potty, get it? Sometimes we ended up in the inventory of other players. Most of the time we ended up in random rooms. Often enough, we would teleport in where other players were gathered. Intrigued, they would join the party.
Yeah, it sounds stupid. You have to have been there.:)
The thing I like most about MOO, though, is that it is just an engine. You can do just about anything with it. For example, many MOOs double as Web servers, processing game data into HTML. Some also speak IRC -- a bot coded in MOO can be a bridge between a MOO and an IRC channel. Many MOOs also generate colored text on the terminal by generating the ANSI escape sequences from MOO code. Picture a scripting language sitting on top of a network interface. The server provides a basic framework, but all the real behaviors are programmed in the scripting language and part of the "database". (A MOO database is a collection of MOO objects, with inheritance, properties, and program code. It's not a relational database.) In a MOO, an object in the game world sense is the same as an object in the programming sense. A "verb" is the term for a function -- you can pass in args like you would in most any language, but these also have an additional layer to allow a verb to also be a command a player types in. Some verbs are only callable as commands, others are only callable as functions -- and some are both! Since new script can be compiled in on the fly, you can change a MOO around significantly without ever having to restart it. (Of course, you can also have MOO code that generates and executes other MOO code.)
The language has some interesting strengths and some key weaknesses. It'll teach you some bad software engineering habits if you let it. On the other hand, its huge flexibility is a good teacher. And it's definitely a wonderful geek toy.
I simply didn't find the plot believable. An adult member of that species became literate in under a day. How the hell could someone THAT INTELLIGENT utterly fail to become at least someone educated simply by being around written words and people who talk? I'm supposed to believe that 3% of that species' population never learned anything or had any motivation whatsoever, despite the fact that their sole purpose involved them moving from couple to couple doing their cogentior thing? That's just hard to swallow. Unless you are keeping them locked up in boxes and only taking them out to breed, they'd have to learn something merely by being awake.
You didn't see the trailer after last night's episode? Apparently they ARE going to involve the Borg. Next week.
I wasn't particularly thrilled with last night's episode. And if they're bringing the Borg into the mix, then that just might cross my threshold of tolerance for how Star Trek history is being rewritten.
AMD CPUs outperform Intel CPUs at similar frequencies. That's why AMD stopped marketing their processors based on their frequency. In some benchmarks, an Itanium running at 900 MHz outperforms 3 GHz Pentium IVs.
Once upon a time, before clock multiplying, MHz meant more than it does now. But even in the 8-bit days, a 6502 running at 1 MHz would perform similarly to an 8086 running at 4.3 MHz.
Slashdot Mirror
I find it interesting that most posts on this thread are talking about video game programming, not video game design. Once upon a time, back when 8-bit processors and 16-color displays were king, one or two people could design and program a game, and probably do the artwork and sound as well. These days, game studios tend to have a small number of designers and plenty of programmers, artists, and Quality Assurance personnel. The article doesn't actually mention programming -- it mentions that the curriculum has courses on game design, and special effects, and has a creative writing requirement.
The whole concept of a college course that teaches game design is amusing, considering that the job title "designer" has half a dozen different meanings. A game designer can be anything from a story writer to a world builder to a game system designer. Some designers use scripting languages and actually do implementation, while most don't. Design-related positions tend to pay less than programming, but more than Quality Assurance or Tech Support. It's also worth noting that designer job security isn't all that great, either. However, you're much more likely to land a world builder job by creating an impressive mod or map for an existing game than by waving a degree around.
If you want to get into video games, then go the programming route. It pays better and there are many more positions available. You get to work very closely with the designers and have some influence in the design of the game itself. Job security is better -- and, you still get to fire up the latest games at work and play them while calling it research!
"Massively Multiplayer" is a bit of a misnomer, in my opinion. NO game today actually allows you to participate with other players en masse. At best, you might interact with dozens of other players at once, but in the current crop of "massive" online games all that means is a big lag fest. You get that many players together and one or both of the following happen: Your 3D card chokes on all the polys and your framerate drops; or your bandwidth can't handle simultaneous updates from all the other players on your screen.
What does it matter if several hundred thousand people play the same game? Only about 10% of them will be logged on at any given time. Only 5% of *those* will be on the same server as you. And of the ones actually logged in, you'll only be able to play with less than 1% of them at a time.
I predict that within the next 10 years we will see games that can rightfully claim to be "massively" multiplayer. These games will have millions of simultaneous players, all sharing one huge game world (instead of dozens of copies of one). Line of sight restrictions won't exist as such -- there won't be any fog keeping you from standing on top of a mountain looking down on a city and being able to make out hundreds of players milling about, all in high resolution breathtakingly clear rendered 3D and in glorious real time.
I can picture a massive starship battle, in fully 3D: There are two sides involved, and each armada has thousands of ships. At the helm of each individual ship is a player much like yourself. You are somewhere in the middle of your side's armada, so you can see hundreds of friendly ships flying in a loose formation toward the cloud of approaching enemies. Your mini-map has a dot for each ship in your fleet and each enemy in sensor range. You tense for battle, then the two fleets collide. The destruction at the leading edge is massive, but it takes practically no time for both fleets to occupy the same space.
At first your only thought is to avoid a head-on collision, but reflexively you start blasting away with your foreward cannons as you begin to dodge. Dozens of explosions dot the spacescape around your ship. Cannon and laser fire arc around between tiny dots you know to be fairly distant ships. You narrowly miss an oncoming enemy and as you bank around you are treated to a glorious explosion as one of your comrades is obliterated. Too bad for him -- but also too bad for the hostile flying cockily through the debris. You're quicker than he is and your cannons shred his ship before he even sees you.
Now that the initial charge is over, the pace slows a bit. Allies group together for the strength of numbers, flying slowly for more maneuverability, surveying the part of the battle nearby to determine where they can deal the most damage...
Something like that could never happen with today's hardware and bandwidth limitations. In ten years? It'd probably be a piece of cake.
Ahh, MOO. This article has given me attacks of nostalgia. I first started writing code in MOO nearly a decade ago. One of the more fun things I did was to code up an interesting object called a Port-O-Potty. It was bigger on the inside than it was on the outside, with an entryway, party room, and men's and women's toilets. (That's just surrealism allowed by clever use of containment and room linking -- not code.) But the fun part was, it would teleport itself around the MOO randomly every few minutes. Port-O-Potty, get it? Sometimes we ended up in the inventory of other players. Most of the time we ended up in random rooms. Often enough, we would teleport in where other players were gathered. Intrigued, they would join the party.
:)
Yeah, it sounds stupid. You have to have been there.
The thing I like most about MOO, though, is that it is just an engine. You can do just about anything with it. For example, many MOOs double as Web servers, processing game data into HTML. Some also speak IRC -- a bot coded in MOO can be a bridge between a MOO and an IRC channel. Many MOOs also generate colored text on the terminal by generating the ANSI escape sequences from MOO code. Picture a scripting language sitting on top of a network interface. The server provides a basic framework, but all the real behaviors are programmed in the scripting language and part of the "database". (A MOO database is a collection of MOO objects, with inheritance, properties, and program code. It's not a relational database.) In a MOO, an object in the game world sense is the same as an object in the programming sense. A "verb" is the term for a function -- you can pass in args like you would in most any language, but these also have an additional layer to allow a verb to also be a command a player types in. Some verbs are only callable as commands, others are only callable as functions -- and some are both! Since new script can be compiled in on the fly, you can change a MOO around significantly without ever having to restart it. (Of course, you can also have MOO code that generates and executes other MOO code.)
The language has some interesting strengths and some key weaknesses. It'll teach you some bad software engineering habits if you let it. On the other hand, its huge flexibility is a good teacher. And it's definitely a wonderful geek toy.
I simply didn't find the plot believable. An adult member of that species became literate in under a day. How the hell could someone THAT INTELLIGENT utterly fail to become at least someone educated simply by being around written words and people who talk? I'm supposed to believe that 3% of that species' population never learned anything or had any motivation whatsoever, despite the fact that their sole purpose involved them moving from couple to couple doing their cogentior thing? That's just hard to swallow. Unless you are keeping them locked up in boxes and only taking them out to breed, they'd have to learn something merely by being awake.
You didn't see the trailer after last night's episode? Apparently they ARE going to involve the Borg. Next week.
I wasn't particularly thrilled with last night's episode. And if they're bringing the Borg into the mix, then that just might cross my threshold of tolerance for how Star Trek history is being rewritten.
Ugh!
AMD CPUs outperform Intel CPUs at similar frequencies. That's why AMD stopped marketing their processors based on their frequency. In some benchmarks, an Itanium running at 900 MHz outperforms 3 GHz Pentium IVs. Once upon a time, before clock multiplying, MHz meant more than it does now. But even in the 8-bit days, a 6502 running at 1 MHz would perform similarly to an 8086 running at 4.3 MHz.