As have I. It came at just the right time, too. I'd just finished playing WC4 (the only Wing Commander game I missed on original release) and was sad that there was no more WC to play.:-)
sure the animated heads are a bit cheesy, but the game still rules
It does still rule. But the question is, does it rule enough to pay $50 for it? For die-hard fans, sure. But the general populace wouldn't. In fact they'd probably slam it over the variety of bugs that still exist in the game. But since it's free, there's little gamers can complain about. i.e. Reseting expectations.:-)
Primarily Java these days. When I was a young'un, I did 3D engines in C, but these days I see little need for doing much at all in C.
Some of my favorite stuff to write is the 4K games. The 4K boundry seems to be sweet-spot that provides me with a challenge worthy of spending time on, as well as confines the game enough to make sure it gets *done*.
BTW, the X libs are the wrong place to start. I spend most of my time in the Java2D APIs, but for serious games (both 2D and 3D) you'll want to use OpenGL.
Have you ever actually worked for a gaming company? The problem is not that they're competitive or that they demand a lot. The problem is that they destroy people's lives and health without providing *anything* in return. (sarcasm)It is, after all, supposed to be a "privilege" to work for a gaming company. Just like it once was a "privilege" to die for a fuedal lord.(/sarcasm) Society cast off those chains long ago, and provided only for common defense. If someone wanted to gain power, they needed to fairly compensate those who chose to serve them.
Minesweeper... no wacky effects, just a short learning curve with a long time to master.
And no one lining up to purchase it...
F-Zero... no real story or eye-candy, just fast.
The original *was* eye-candy for its time. It did spectacular. The sequel was low on looks to provide the feeling of speed. It was lots of fun, IMHO, but it flunked on the market.
Silent Hill... not pushing the envelope graphically, but scary as hell.
Silent... what?
I suppose I should have clarified my point. If you want to make a fun game to release for little or no money, then player expectations will be lower. Privteer Remake is a perfect example of this. The game is merely an update to a retro title, has a variety of gameplay bugs, and has true-to-original graphics. I (and many others) love it to death.:-)
But if you want to make a game for profit, then you *must* compete. Not as easy as it might seem.:-(
I know this was posted as an "uninformed" opinion, but can you qualify your comment somehow?
It's a combination of personal experiences and observations. Let's just leave it at that.:-)
I do work at a smaller studio, and we're not owned by any dark international conglomerate, but I've seen 0% of all the negative stuff these guys are talking about. Decent hours, decent pay, and I get a lot of creative input (even as a programmer).
Good for you! Jobs like that tend to be from the people who went from "spare time" programming to publishing. If they can keep up the momentum, then they can keep in business.
However, while those gaming jobs *do* exist, it may be hard to find a different line of work. The programming industry as a whole tends to "taint" you depending on the work you've done before. (Really sucky, I know.) So even if you don't want to work for a gaming company, you may find that other companies may not like you because of your gaming experience.:-(
Good luck, though. I hope you never see any of what I'm talking about.
Which would be perfectly good logic if we weren't talking about a language for describing recipes.:-) Being a "meta-language" that's targetted at semi-programmers, it would make most sense if the syntax was as simplistic as possible. Part of that is that the instructions should be crafted such that long lines shouldn't happen. Just like BASIC.;-)
The answer is, "The search engine that comes after Google." Which, if you think about it, makes for a really annoying reason to use the word "penultimate".:-)
You don't need a big budget for a good story line.
No, you don't. But players will tend to expect very high standards, so it's difficult to accomplish today without sinking in the money. For example, Wing Commander Privateer had animated heads and text printing out. (If you got the CDROM version like me, you were treated to some really corny voice acting too!) Wing Commander 3 went to full movies for story nary a year or two later.
Now do you think anyone would be happy if the next Wing Commander for the PC had animated heads and printed out text? Pfff, I wish.:-)
The one exception is that you can get away with murder if you reset expectations. Wing Commander: Prophecy for the Game Boy was just released. They have story panels, not even talking heads!
Unfortunately, and in my opinion, this follow-the-leader approach has lead to stagnation in CPU development.
Nonsense. As a game developer you should know that CPU development has jack to do with modern games. Graphics card designs are the major push for more immersive experiences, and they have been changing at break-neck speeds. Graphics have constantly become more and more "realistic" with things like programmable pixel shaders. Real time raytracing GPUs are on the horizon, and promise to offer a gaming experience like no other.
So why the heck are games so dull? Primarily because the gameplay is recycled. Everyone copies Quake/Doom and adds their own spin on it. Where's the push for *new* gaming experiences? Games like Wing Commander, BioForge, Secret of Monkey Island, Doom, Privateer, System Shock, and Half-life are all remembered fondly because they pushed the boundries of gameplay. In some cases they also pushed the boundries of hardware requirements, but that's because they needed the horsepower to create their fun game environment, not the other way around!
Just because everyone needs an uninformed opinion, here's mine:
Stay the hell away from the "gaming industry" as a career. Find an interesting job in programming something else, and write games as a hobby. If you get anywhere near the gaming industry, they will chew you up and spit you out like a piece of used tabacco. You're far better off writing games in your spare time for fun. No, you won't be the one to write the next Quake, but you will have time to spend with your family as well as the ability to exercise your own creative will.
If you find that your blood still boils to write games, then may I suggest writing it independet of the big boys? It's the only way you're going to get to do what you want to do. Once you have a demo done, you can try to get a publisher to give you funding to finish it.
As for actual game designs, it's taken me a long time to figure out what's "fun" and what isn't. The answer? Cheap-ass effects out the wahzoo. Seriously! The difference between a dull game and a fun game may be how adreniline-pumping the explosions look, or how you shake the screen, or perhaps that quirky physics trick that causes the bad guy to go flying after you punched him three times! The more cheap effects you can pack in, the more you can crank up the action and immerse the player. The player will find it "fun" and will keep coming back.
Story-lines also help, but these are damn hard to add on a budget. You need a good story writer that can provide a suspenseful and intriguing story (hard to find!), and you need good voice actors at a minimum. For a *really* immersive story, you need a complete video production team. Not easy to come by.
The last bit of advice I have, is to not get too carried away with how pretty your game looks. I said "cheap effects", not expensive ones! A player may notice your cool lighting engine ONCE before completely ignoring it. You have to ask yourself if it was really worth the work to add it (i.e. did it add to the game?) or was it just a personal "Look what I can do!" moment?
That's what you think. Ever been slammed by Inktomi? The damn bot just keeps coming! It doesn't stop, it just keeping hitting the same URLs over and over and over! I've seen it account for as much as 50% of a websites hits for a given month!
PHP4 aside, I'm not really sure what is so difficult to understand about OOP, so maybe you can help me understand the mental block some people have. Here's my five minute buildup. Let me know where it is that you had hangups.
OOP at its core is a way of designing your code so that related data and behaviors are encapsulated together. That is OOP. Period. End of story. Many languages can implement this, including JavaScript, PHP, and even C! (Amazing what one can accomplish with some function pointers.;-))
This means that the proper way to design code is now to achieve the end goal by first matching each object to a "real" concept that will exist in the final product. This allows for a "divide and conquer" strategy whereby programmers flesh out each object independent of the rest.
Unfortuately, OOP leads to several related concepts which tend to be quite confusing. For example, inheritence is a natural extension to OOP philosophy. By piling up contained data and methods, an object can go from being a generic "catch-all" to a specific description of the modelled object.
Once you have inheritence, though, then you suddenly have a situation involving polymorphism. You can refer to an object by its parent type (e.g. Car) and expect it to work just fine, but you can also investgate some of the special features of the more specific sub-class (e.g. Cavalier).
Even more interesting, is the concept of an ADT. At its core, ADT really just describes how a given set of entities can be used to define another. A common example is money. You have dollars, and you have cents. It differs from a regular number in that 1/100th is the smallest unit allowed. An ADT encapsulation allows you to enforce these rules. This example, however, tends to be rather... erm... abstract.
A more solid example is a plane. A plane is an object. But a plane is made up of a fusilage, wings, and engines. Each of those are objects unto themselves, which can be further broken down into concepts like control surfaces, turbines, windows, etc. The only difference with computers, is that we stop when we can finally represent the structure at the lowest level a computer can understand: binary encodings. For practical purposes, binary encodings refers to integers, floating point numbers, and strings of bytes or words.
Am I forgetting any core concepts here?
The two things I usually see people trip up on are:
1. A false sense of encapsulation. Encapsulation implies instantiation. i.e. The code is a description of a data structure. You should be able to reuse that data structure as many times as you like, and you should be able to use it as a single entity. This is not always understood, and results in downright silly "OO" implementations like that seen in Visual Basic and VBA. (VB simply collects a set of functions under a given filename. There's no real opportunity to instantiate the object and pass it around in variables.)
2. Difficulty in breaking the linear code habit. Many coders never really got beyond the concept of writing pages and pages of procedural code. The only reason why they use functions at all is because they were told to. They tend to misunderstand why a function is discreet, and have been known to heavily abuse global variables. Unfortunately, this problem goes deeper than a misunderstanding of OOP, and must be corrected before OOP can be introduced at all.
Are you trying to scar the poor kid for life? ObjC has about as much in common with C as COBOL has with LISP!
For all the bad press it gets, Java really is the best OOP language for those just getting started. *Especially* if they've programmed C before. C# is also acceptable, albeit mostly a ripoff of Java.:-)
That's not the "breakEggs" I need on devil's night, so we're back to square one: having people learn to program properly.
What the hell are you talking about? The language is designed to encapsulate recipe semantics. That's it. If you need something other than cracking the shell, dropping the egg into the container, and disposing of the shell, then you need a different function. (But what else would you need for cooking and baking?!?)
the code wouldn't even compile if you were to try.
That's because it's psuedo code. I don't know what language he uses, so I tried not to assume much. Note the use of "const" for example, instead of "static final int".
Not only is it a poor explanation
Ah, but that's the key. It's not an explanation of OOP. It's an explanation of how to code something using OOP structures. Once he starts coding it, the rest should flow naturally.:-)
No, I tried to help a poor sap wrap his head around OOP code without confusing the hell out of him. The number one issue with teaching OOP to an existing programmer is that he tends not to understand how it relates to what he's coded. Encapsulation is the key to helping them understand basic objects. Once they understand basic data encapsulation, then mutators start to make sense. ("Oh, you mean I can write changeDirection(int dir) in the class instead of changeDirection(struct *dirStruct, int dir)? Cool!")
Once that encapsulation is down, then Objects (including objects as Abstract Data Types) make sense. With an understanding of objects in hand (even if it's still rather imprecise), the concept of inheritance begins to flow naturally. Inhereitance leads to an understanding of abstract objects, and abstract objects leads to an understanding of polymorphism.
Backwards? Hell, yeah! But it works. If you don't believe me, go try explaining what polymorphism is to a COBOL programmer. Or a C programmer for that matter. They'll constantly ask you for concrete examples. If you give them one, they'll say "Oh, that's what polymorphism is!" To which you'll reply, "No, no, no! That's just an example of polymorphism!" Which brings you back to blank stares and more requests for examples. Rinse and repeat.
Slashdot Mirror
I have been burning off weeks playing it,
:-)
:-)
As have I. It came at just the right time, too. I'd just finished playing WC4 (the only Wing Commander game I missed on original release) and was sad that there was no more WC to play.
sure the animated heads are a bit cheesy, but the game still rules
It does still rule. But the question is, does it rule enough to pay $50 for it? For die-hard fans, sure. But the general populace wouldn't. In fact they'd probably slam it over the variety of bugs that still exist in the game. But since it's free, there's little gamers can complain about. i.e. Reseting expectations.
Amen, brother. Amen. :-)
I'm curious... do you do this yourself?
Yes.
What do you use?
Primarily Java these days. When I was a young'un, I did 3D engines in C, but these days I see little need for doing much at all in C.
Some of my favorite stuff to write is the 4K games. The 4K boundry seems to be sweet-spot that provides me with a challenge worthy of spending time on, as well as confines the game enough to make sure it gets *done*.
BTW, the X libs are the wrong place to start. I spend most of my time in the Java2D APIs, but for serious games (both 2D and 3D) you'll want to use OpenGL.
Have you ever actually worked for a gaming company? The problem is not that they're competitive or that they demand a lot. The problem is that they destroy people's lives and health without providing *anything* in return. (sarcasm)It is, after all, supposed to be a "privilege" to work for a gaming company. Just like it once was a "privilege" to die for a fuedal lord.(/sarcasm) Society cast off those chains long ago, and provided only for common defense. If someone wanted to gain power, they needed to fairly compensate those who chose to serve them.
Write your own? If you don't mind Java, Xith3D and JMonkeyEngine provide excellent scenegraphs to start from.
If there is one kind of game that I think anyone on slashdot will love it is this:
The traditional, immersive, huge, excellent role-playing game
I hate role-playing games. Think we can get someone to make another Wing Commander?
?Take Fallout... crappy graphics, amazing depth.
:-)
:-(
And, what, 10 years out of date?
Minesweeper... no wacky effects, just a short learning curve with a long time to master.
And no one lining up to purchase it...
F-Zero... no real story or eye-candy, just fast.
The original *was* eye-candy for its time. It did spectacular. The sequel was low on looks to provide the feeling of speed. It was lots of fun, IMHO, but it flunked on the market.
Silent Hill... not pushing the envelope graphically, but scary as hell.
Silent... what?
I suppose I should have clarified my point. If you want to make a fun game to release for little or no money, then player expectations will be lower. Privteer Remake is a perfect example of this. The game is merely an update to a retro title, has a variety of gameplay bugs, and has true-to-original graphics. I (and many others) love it to death.
But if you want to make a game for profit, then you *must* compete. Not as easy as it might seem.
The * beside the parent's handle indicates that (s)he is a paid subscribed to Slashdot.
:-)
He, thank you.
I know this was posted as an "uninformed" opinion, but can you qualify your comment somehow?
:-)
:-(
It's a combination of personal experiences and observations. Let's just leave it at that.
I do work at a smaller studio, and we're not owned by any dark international conglomerate, but I've seen 0% of all the negative stuff these guys are talking about. Decent hours, decent pay, and I get a lot of creative input (even as a programmer).
Good for you! Jobs like that tend to be from the people who went from "spare time" programming to publishing. If they can keep up the momentum, then they can keep in business.
However, while those gaming jobs *do* exist, it may be hard to find a different line of work. The programming industry as a whole tends to "taint" you depending on the work you've done before. (Really sucky, I know.) So even if you don't want to work for a gaming company, you may find that other companies may not like you because of your gaming experience.
Good luck, though. I hope you never see any of what I'm talking about.
Which would be perfectly good logic if we weren't talking about a language for describing recipes. :-) Being a "meta-language" that's targetted at semi-programmers, it would make most sense if the syntax was as simplistic as possible. Part of that is that the instructions should be crafted such that long lines shouldn't happen. Just like BASIC. ;-)
LOL! Close, very close. :-)
:-)
The answer is, "The search engine that comes after Google." Which, if you think about it, makes for a really annoying reason to use the word "penultimate".
You don't need a big budget for a good story line.
:-)
No, you don't. But players will tend to expect very high standards, so it's difficult to accomplish today without sinking in the money. For example, Wing Commander Privateer had animated heads and text printing out. (If you got the CDROM version like me, you were treated to some really corny voice acting too!) Wing Commander 3 went to full movies for story nary a year or two later.
Now do you think anyone would be happy if the next Wing Commander for the PC had animated heads and printed out text? Pfff, I wish.
The one exception is that you can get away with murder if you reset expectations. Wing Commander: Prophecy for the Game Boy was just released. They have story panels, not even talking heads!
Unfortunately, and in my opinion, this follow-the-leader approach has lead to stagnation in CPU development.
Nonsense. As a game developer you should know that CPU development has jack to do with modern games. Graphics card designs are the major push for more immersive experiences, and they have been changing at break-neck speeds. Graphics have constantly become more and more "realistic" with things like programmable pixel shaders. Real time raytracing GPUs are on the horizon, and promise to offer a gaming experience like no other.
So why the heck are games so dull? Primarily because the gameplay is recycled. Everyone copies Quake/Doom and adds their own spin on it. Where's the push for *new* gaming experiences? Games like Wing Commander, BioForge, Secret of Monkey Island, Doom, Privateer, System Shock, and Half-life are all remembered fondly because they pushed the boundries of gameplay. In some cases they also pushed the boundries of hardware requirements, but that's because they needed the horsepower to create their fun game environment, not the other way around!
Just because everyone needs an uninformed opinion, here's mine:
Stay the hell away from the "gaming industry" as a career. Find an interesting job in programming something else, and write games as a hobby. If you get anywhere near the gaming industry, they will chew you up and spit you out like a piece of used tabacco. You're far better off writing games in your spare time for fun. No, you won't be the one to write the next Quake, but you will have time to spend with your family as well as the ability to exercise your own creative will.
If you find that your blood still boils to write games, then may I suggest writing it independet of the big boys? It's the only way you're going to get to do what you want to do. Once you have a demo done, you can try to get a publisher to give you funding to finish it.
As for actual game designs, it's taken me a long time to figure out what's "fun" and what isn't. The answer? Cheap-ass effects out the wahzoo. Seriously! The difference between a dull game and a fun game may be how adreniline-pumping the explosions look, or how you shake the screen, or perhaps that quirky physics trick that causes the bad guy to go flying after you punched him three times! The more cheap effects you can pack in, the more you can crank up the action and immerse the player. The player will find it "fun" and will keep coming back.
Story-lines also help, but these are damn hard to add on a budget. You need a good story writer that can provide a suspenseful and intriguing story (hard to find!), and you need good voice actors at a minimum. For a *really* immersive story, you need a complete video production team. Not easy to come by.
The last bit of advice I have, is to not get too carried away with how pretty your game looks. I said "cheap effects", not expensive ones! A player may notice your cool lighting engine ONCE before completely ignoring it. You have to ask yourself if it was really worth the work to add it (i.e. did it add to the game?) or was it just a personal "Look what I can do!" moment?
You're missing the part about "best OOP language to start with". A programmers first language, period, should never be an object oriented one. :-)
That's what you think. Ever been slammed by Inktomi? The damn bot just keeps coming! It doesn't stop, it just keeping hitting the same URLs over and over and over! I've seen it account for as much as 50% of a websites hits for a given month!
Wrong answer. Obviously, you have not read Hitchhiker's Guide to the Galaxy. NEXT!
In addition to being the penultimate search engine
;-)
What is the ultimate search engine?
(If I get a Hitchhicker's Guide answer, I'm going to strangle someone.)
My favourite OO language is PHP4
;-))
*Shudder*
PHP4 aside, I'm not really sure what is so difficult to understand about OOP, so maybe you can help me understand the mental block some people have. Here's my five minute buildup. Let me know where it is that you had hangups.
OOP at its core is a way of designing your code so that related data and behaviors are encapsulated together. That is OOP. Period. End of story. Many languages can implement this, including JavaScript, PHP, and even C! (Amazing what one can accomplish with some function pointers.
This means that the proper way to design code is now to achieve the end goal by first matching each object to a "real" concept that will exist in the final product. This allows for a "divide and conquer" strategy whereby programmers flesh out each object independent of the rest.
Unfortuately, OOP leads to several related concepts which tend to be quite confusing. For example, inheritence is a natural extension to OOP philosophy. By piling up contained data and methods, an object can go from being a generic "catch-all" to a specific description of the modelled object.
Once you have inheritence, though, then you suddenly have a situation involving polymorphism. You can refer to an object by its parent type (e.g. Car) and expect it to work just fine, but you can also investgate some of the special features of the more specific sub-class (e.g. Cavalier).
Even more interesting, is the concept of an ADT. At its core, ADT really just describes how a given set of entities can be used to define another. A common example is money. You have dollars, and you have cents. It differs from a regular number in that 1/100th is the smallest unit allowed. An ADT encapsulation allows you to enforce these rules. This example, however, tends to be rather... erm... abstract.
A more solid example is a plane. A plane is an object. But a plane is made up of a fusilage, wings, and engines. Each of those are objects unto themselves, which can be further broken down into concepts like control surfaces, turbines, windows, etc. The only difference with computers, is that we stop when we can finally represent the structure at the lowest level a computer can understand: binary encodings. For practical purposes, binary encodings refers to integers, floating point numbers, and strings of bytes or words.
Am I forgetting any core concepts here?
The two things I usually see people trip up on are:
1. A false sense of encapsulation. Encapsulation implies instantiation. i.e. The code is a description of a data structure. You should be able to reuse that data structure as many times as you like, and you should be able to use it as a single entity. This is not always understood, and results in downright silly "OO" implementations like that seen in Visual Basic and VBA. (VB simply collects a set of functions under a given filename. There's no real opportunity to instantiate the object and pass it around in variables.)
2. Difficulty in breaking the linear code habit. Many coders never really got beyond the concept of writing pages and pages of procedural code. The only reason why they use functions at all is because they were told to. They tend to misunderstand why a function is discreet, and have been known to heavily abuse global variables. Unfortunately, this problem goes deeper than a misunderstanding of OOP, and must be corrected before OOP can be introduced at all.
If you already know C, look at Objective-C.
:-)
Are you trying to scar the poor kid for life? ObjC has about as much in common with C as COBOL has with LISP!
For all the bad press it gets, Java really is the best OOP language for those just getting started. *Especially* if they've programmed C before. C# is also acceptable, albeit mostly a ripoff of Java.
That's not the "breakEggs" I need on devil's night, so we're back to square one: having people learn to program properly.
What the hell are you talking about? The language is designed to encapsulate recipe semantics. That's it. If you need something other than cracking the shell, dropping the egg into the container, and disposing of the shell, then you need a different function. (But what else would you need for cooking and baking?!?)
I do what I can. Thanks for noticing. :-)
Read who I was replying to. He got modded down to -1 for adding a troll at the end of his otherwise perfectly acceptable post.
the code wouldn't even compile if you were to try.
:-)
That's because it's psuedo code. I don't know what language he uses, so I tried not to assume much. Note the use of "const" for example, instead of "static final int".
Not only is it a poor explanation
Ah, but that's the key. It's not an explanation of OOP. It's an explanation of how to code something using OOP structures. Once he starts coding it, the rest should flow naturally.
you misdefined oop
No, I tried to help a poor sap wrap his head around OOP code without confusing the hell out of him. The number one issue with teaching OOP to an existing programmer is that he tends not to understand how it relates to what he's coded. Encapsulation is the key to helping them understand basic objects. Once they understand basic data encapsulation, then mutators start to make sense. ("Oh, you mean I can write changeDirection(int dir) in the class instead of changeDirection(struct *dirStruct, int dir)? Cool!")
Once that encapsulation is down, then Objects (including objects as Abstract Data Types) make sense. With an understanding of objects in hand (even if it's still rather imprecise), the concept of inheritance begins to flow naturally. Inhereitance leads to an understanding of abstract objects, and abstract objects leads to an understanding of polymorphism.
Backwards? Hell, yeah! But it works. If you don't believe me, go try explaining what polymorphism is to a COBOL programmer. Or a C programmer for that matter. They'll constantly ask you for concrete examples. If you give them one, they'll say "Oh, that's what polymorphism is!" To which you'll reply, "No, no, no! That's just an example of polymorphism!" Which brings you back to blank stares and more requests for examples. Rinse and repeat.