Basic is a good language for learning programming. It allows you to focus on core mechanics (flow control, predication, logic, arithmetic, loops, recursiveness, etc) without focusing on higher level language concepts. As long as a program remains small (which is the point here), GOTOs are fine.
Higher level languages can be more confusing to kids. Objects, factories, inheritance and all that stuff is easier for adult minds to comprehend since their idea is modeled after real world concepts, but kids don't have those concepts fully absorbed yet (or at all) anyway.
In fact, what I've observed is that kids don't have too much trouble with assembly either. It's low level, simple and repetitive. You have "boxes" you put stuff in, operations you do on them, etc. As long as you don't get into the more exotic instruction sets, you're fine. And sure, and all address based operations might be a little complex.
That's why I actually find basic quite good as a learning language. A kid who starts learning about programming concepts at 8-10 years old has a chance at becoming a very strong programmer later on. I have seen it many times. So basic is a really good idea. In fact, I've used basic256 for one of my kids.
Don't snob the language. You want something barebones. It's the computer science concepts they get exposed to at an early age that are important. Writing a "guess my number" or "guess my animal" game is a great growing exercise.
Programming the SPUs is super interesting, and you need a cell for that. The GPU on the ps3 is not even that interesting. But the SPUs are. Writing for SPUs is a great programming exercise. It sucks if that capability goes away.
There is something to be said about knowing the structure of your codebase. I already see intellisense users jumping around and editing code from locations they have no idea about, this will be even worse. It really pays off to understand the file/directory/package structure of your codebase, as opposed to jumping to unknown locations, making an edit and bailing out.
Intellisense/ctags are great when they extend your knowledge of the codebase, but they shouldn't be a substitute for having some amount of awareness.
Code reviews are somewhat useful for small changes. But I find that for large changes, they are TOO LATE. If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes. He basically has to scratch most of his work. And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".
Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.
That's why I like to have quick whiteboard sessions before someone starts implementing something. I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc. When those things are caught early on, is it almost free to correct them. But later, there is a cost. If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.
I work at a large video game company. I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface). Every sees the short term. It is easy for them to understand that something is done when they see it in the game. But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.
So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.
What is this illusion that xbox was a solid #2 behind the ps2? First, even on the xbox' strongest territory, North America, xbox was a distant second to the ps2. Second, North America was the only territory where microsoft was ahead of nintendo. In Europe xbox was more or less tied with the gamecube, and in japan we all know the xbox story.
This really speaks highly of microsoft's marketing, since a lot of people in North America (including designers it would seem) seem to be under the impression that in terms of install base, microsoft wasn't that far behind from sony.
God of War was the perfect game in terms of length. I'm a dad with two very young daughters, and I work in the videogames industry so I do rather long hours. Like the author, after work & family I do not have much time for games.
So God of War was awesome. I always felt like the game was moving forward. The story was intense yet I spent most of my time playing and not watching cut scenes. At normal difficulty, it felt hard enough but not crazy hard. The puzzles were not ridiculous. And most importantly, I was able to finish it without spending too much time on it, which left me hungry for more but not frustrated.
ICO was another such game, although arguably very easy and a bit short. But I'm not complaining.
And as much as I love the Grand Theft Auto games, I didn't finish GTA3, barely finished Vice City and am *nowhere* near finishing San Andreas despite pouring significant time (compared to my other games) in it, to the point that I'm dropping it. (too many bad quality non-optional mini-games like flying the plane, the helicopter, etc, that can't compare with the quality of the core game).
The author is confusing ugly with evil. Perhaps he should be teaching his son not to judge people on appearances?
Good point. His kid would probably be scared by a real life person who suffered massive face injuries too. I would probably be a little bit scared by that too.
Something no one has mentionned yet... what happens when you really get into that tennis game and start really puting some motion into your strokes, and then the controller slides from your hand and smashes into the wall?
Are they going to be solid? *Really* solid? Or padded?
Even if the game is only exclusive on 360 for a few months and then comes out on other platforms (as is currently the case with ps2 GTA), the majority of the sales happen during the exclusivity period. After that, the hype pretty much dies. I was amazed to see how low the sales numbers were for the GTA games on xbox.
So, whatever is the case with this GTA exclusivity for 360, it's a huge blow against sony. In north america at least.
Does anyone know who was the first console manufacturer that decided to initially sell its console at a loss? I know that it wasn't always the case. I don't believe the NES, SNES or SMS were sold at a loss.
Oh ok, what I thought you meant (by sarcasm) was that since most game developers work on platforms they won't meet outside of a game development job (speaking of consoles here, not PC), that once they leave the game dev arena they would actually have trouble on platfomrs they don't know.
Most programmers who write game code are used to writing code within strict resource requirements (mem, CPU, etc), especially when it's for consoles (ps2, psp, etc). Depending on their role, most of them are also required to write code that can execute with very strict time limits.
They basically touch fields such as rendering, networking, AI, performance & realtime, memory management.
In the end, are you telling me that someone with even some of those skills could not find a job outside the gaming industry in less than a second? (They already fit pretty much any embedded programmer offering, and many more).
Huh? No, those 9 pages of memory get freed and are available for re-use, but they could only satisfy a contiguous memory request the size of 9 pages. Hence, the fragmentation. But that memory is not wasted.
You obviously haven't heard of the ubisoft burn out stories... Keep in mind, the #1 player in any field is always the one under the spotlight. A lot of game companies can do a lot of awful stuff, but only EA is under the spotlight. Likewise, a lot of mainstream software companies can do a lot of awful stuff, but only microsoft is under the spotlight.
The long hours is an industry wide issue. And it is actually much worse at small independant studios that get paid per milestone. There's just no UbiSpouse or Take2Spouse yet.
The ps3 will surely have way more bus contention issues than a PC. While the high level issues of concurrent programming will be comparable to any multi-processor architecture, once you get into the low level details, the similarities will end.
You should start doing less hours in order to make time for your job hunt. Yes, your managers will probably frown upon for doing so, but it would probably take a few weeks of you not doing crazy overtime for them to decide to do something major like firing you. So you're really buying yourself some time. I don't think you would be fired for doing a few weeks of "non-crazy" work hours.
You sound like an armchair general talking about how it is in the trenches (posting as an AC, no less).
John Carmack is not the greatest programmer, but he is a damn fine programmer. He has shipped tons of games, and shipping games is an incredibly difficult thing. You also have to keep in mind that until quake2 included, he handled almost all major programming tasks (rendering, networking, architecture). Doom is one of the first games I've seen to cleverly use the same client/server architecture whether you are playing a single player or multiplayer game. Carmack is an extremely focused and fast programmer that ships games.
It is just soooo easy to look at code and call out its flaws. Would you like to release some of your code online for all of us to scrutinize?
The benchmarks show, by the author's own admission, that the java version runs at about 60% of the C version's speed. That's to be expected, and one must keep in mind that the only part that java slowed was the part that runs on the CPU. All the work that is offloaded to the GPU would not suffer from that drop in speed.
I would like to see performance benchmarks done on an older platform where there is not huge amounts of L1 and L2 instruction caches.
Also, a 40% drop in execution speed is very significant. While Quake2 may run at "only" 200 instead of 300 on a modern machine, if we were looking at a more complex game that was barely making 30 fps on an average machine by today's standards, that 40% drop in performance would be much more noticeable.
I am wary of benchmarks that are done on machines that totally overpower the app they are running.
Actually, on embedded platforms where performance is critical (game consoles, for example), you want absolute control of your memory layout in order to avoid fragmentation. I don't know if you've had experience with memory fragmentation, but it will slow execution down to a crawl. As good as a virtual machine may be about properly organizing memory, it cannot be better than a good programmer with intimate knowledge of his app's mem usage.
You also want execution to be completely deterministic and certainly don't want a garbage collector to be scheduled to run right when you expect it the least and completely trash your cache memory. I know that you can have some degree of control on when your GC kicks in and whether it should try to run in long stints or in regular and sporadic stints, but it's still not 100% control.
On a platform with fixed hardware, if you give up some control and your competitor doesn't, he will have the edge on performance.
It is not until I got to work on high performance embedded software that I finally brutally realized how, in specific cases, having 100% control on the underlying platform will make the difference between good and bad performance. It is not until you reach the limits of a platform that you realize how having full control
Having said this, I agree that a Java app can be plenty fast. However, it is hard to say how fast that java port of quake2 is until you run it on the typical hardware we had when quake2 first came out. If you run the native quake2 and java quake 2 on a PC today, they will both be blazing fast. But I would like to see how the java version performs on a PC that would *just* reach 60 fps for a native quake2. That would be interesting.
Slashdot Mirror
Basic is a good language for learning programming. It allows you to focus on core mechanics (flow control, predication, logic, arithmetic, loops, recursiveness, etc) without focusing on higher level language concepts. As long as a program remains small (which is the point here), GOTOs are fine.
Higher level languages can be more confusing to kids. Objects, factories, inheritance and all that stuff is easier for adult minds to comprehend since their idea is modeled after real world concepts, but kids don't have those concepts fully absorbed yet (or at all) anyway.
In fact, what I've observed is that kids don't have too much trouble with assembly either. It's low level, simple and repetitive. You have "boxes" you put stuff in, operations you do on them, etc. As long as you don't get into the more exotic instruction sets, you're fine. And sure, and all address based operations might be a little complex.
That's why I actually find basic quite good as a learning language. A kid who starts learning about programming concepts at 8-10 years old has a chance at becoming a very strong programmer later on. I have seen it many times. So basic is a really good idea. In fact, I've used basic256 for one of my kids.
Don't snob the language. You want something barebones. It's the computer science concepts they get exposed to at an early age that are important. Writing a "guess my number" or "guess my animal" game is a great growing exercise.
Cheers,
Alban
Programming the SPUs is super interesting, and you need a cell for that. The GPU on the ps3 is not even that interesting. But the SPUs are. Writing for SPUs is a great programming exercise. It sucks if that capability goes away.
There is something to be said about knowing the structure of your codebase. I already see intellisense users jumping around and editing code from locations they have no idea about, this will be even worse. It really pays off to understand the file/directory/package structure of your codebase, as opposed to jumping to unknown locations, making an edit and bailing out. Intellisense/ctags are great when they extend your knowledge of the codebase, but they shouldn't be a substitute for having some amount of awareness.
Code reviews are somewhat useful for small changes. But I find that for large changes, they are TOO LATE. If someone has gone forward and made non significant changes to your software, and you happen to catch his misconceptions during the code review (dependencies he shouldn't have pulled in, improper encapsulation, volatile and frequent usage of memory, etc), he won't be able to just "address" your concerns with a few changes. He basically has to scratch most of his work. And unfortunately, few managers will see the benefit of "implementing something" better since that requires more time, and the feature as implemented "works".
Likewise, when the software design is done too long before the actual task gets to the implementation phase, the design may be out of touch by the time you get there because new constraints and problems have been discovered since the design phase.
That's why I like to have quick whiteboard sessions before someone starts implementing something. I like to know the dependencies their module will pull in, the services it will require, I want to make sure the module is kept as ignorant as possible in terms of what it knows about the rest of the system, etc. When those things are caught early on, is it almost free to correct them. But later, there is a cost. If the task is long, I like to see multiple snapshots along the way to again course correct anything before it gets too far down the road.
I work at a large video game company. I don't believe things always were the way they are now, but right now everything is tasked against "features" and it is hard for most managers to understand the necessity of infrastructure work, of unit tests, of proper module encapuslation and definition of dependencies (otherwise you find your unit tests impossible to write using your module's public interface). Every sees the short term. It is easy for them to understand that something is done when they see it in the game. But it is harder for them to understand that you want to make the process of software development more predictable, you don't want half the features in the game to be broken half the time and the shipping product to just be an instant snapshot of working features that will break as soon as the next cycle starts.
So, code reviews are useful, but they really aren't the most useful thing since they occur TOO LATE.
What is this illusion that xbox was a solid #2 behind the ps2? First, even on the xbox' strongest territory, North America, xbox was a distant second to the ps2. Second, North America was the only territory where microsoft was ahead of nintendo. In Europe xbox was more or less tied with the gamecube, and in japan we all know the xbox story.
This really speaks highly of microsoft's marketing, since a lot of people in North America (including designers it would seem) seem to be under the impression that in terms of install base, microsoft wasn't that far behind from sony.
Is the threat still in effect if the broadcom driver is used under linux with ndiswrapper?
God of War was the perfect game in terms of length. I'm a dad with two very young daughters, and I work in the videogames industry so I do rather long hours. Like the author, after work & family I do not have much time for games.
So God of War was awesome. I always felt like the game was moving forward. The story was intense yet I spent most of my time playing and not watching cut scenes. At normal difficulty, it felt hard enough but not crazy hard. The puzzles were not ridiculous. And most importantly, I was able to finish it without spending too much time on it, which left me hungry for more but not frustrated.
ICO was another such game, although arguably very easy and a bit short. But I'm not complaining.
And as much as I love the Grand Theft Auto games, I didn't finish GTA3, barely finished Vice City and am *nowhere* near finishing San Andreas despite pouring significant time (compared to my other games) in it, to the point that I'm dropping it. (too many bad quality non-optional mini-games like flying the plane, the helicopter, etc, that can't compare with the quality of the core game).
P.S: I hope the GoW 2 runs at 60 fps
Good point. His kid would probably be scared by a real life person who suffered massive face injuries too. I would probably be a little bit scared by that too.
...the previous round, and the round before.
Why do people feel like they have to write editorials about this?
Something no one has mentionned yet... what happens when you really get into that tennis game and start really puting some motion into your strokes, and then the controller slides from your hand and smashes into the wall?
Are they going to be solid? *Really* solid? Or padded?
Even if the game is only exclusive on 360 for a few months and then comes out on other platforms (as is currently the case with ps2 GTA), the majority of the sales happen during the exclusivity period. After that, the hype pretty much dies. I was amazed to see how low the sales numbers were for the GTA games on xbox.
So, whatever is the case with this GTA exclusivity for 360, it's a huge blow against sony. In north america at least.
Thanks..... the ps1 and ps2 were not selling at a loss initially?
Does anyone know who was the first console manufacturer that decided to initially sell its console at a loss? I know that it wasn't always the case. I don't believe the NES, SNES or SMS were sold at a loss.
Would be curious to find out!
Oh ok, what I thought you meant (by sarcasm) was that since most game developers work on platforms they won't meet outside of a game development job (speaking of consoles here, not PC), that once they leave the game dev arena they would actually have trouble on platfomrs they don't know.
So, my bad!
Your (sarcastic, I take) reply implies that the only difficulty you see in software engineering is systems programming.
Most programmers who write game code are used to writing code within strict resource requirements (mem, CPU, etc), especially when it's for consoles (ps2, psp, etc). Depending on their role, most of them are also required to write code that can execute with very strict time limits.
They basically touch fields such as rendering, networking, AI, performance & realtime, memory management.
In the end, are you telling me that someone with even some of those skills could not find a job outside the gaming industry in less than a second? (They already fit pretty much any embedded programmer offering, and many more).
Not exactly, since at time goes buy, manufacturing costs will quickly decrease.
Huh? No, those 9 pages of memory get freed and are available for re-use, but they could only satisfy a contiguous memory request the size of 9 pages. Hence, the fragmentation. But that memory is not wasted.
You obviously haven't heard of the ubisoft burn out stories... Keep in mind, the #1 player in any field is always the one under the spotlight. A lot of game companies can do a lot of awful stuff, but only EA is under the spotlight. Likewise, a lot of mainstream software companies can do a lot of awful stuff, but only microsoft is under the spotlight.
The long hours is an industry wide issue. And it is actually much worse at small independant studios that get paid per milestone. There's just no UbiSpouse or Take2Spouse yet.
The ps3 will surely have way more bus contention issues than a PC. While the high level issues of concurrent programming will be comparable to any multi-processor architecture, once you get into the low level details, the similarities will end.
You should start doing less hours in order to make time for your job hunt. Yes, your managers will probably frown upon for doing so, but it would probably take a few weeks of you not doing crazy overtime for them to decide to do something major like firing you. So you're really buying yourself some time. I don't think you would be fired for doing a few weeks of "non-crazy" work hours.
You sound like an armchair general talking about how it is in the trenches (posting as an AC, no less).
John Carmack is not the greatest programmer, but he is a damn fine programmer. He has shipped tons of games, and shipping games is an incredibly difficult thing. You also have to keep in mind that until quake2 included, he handled almost all major programming tasks (rendering, networking, architecture). Doom is one of the first games I've seen to cleverly use the same client/server architecture whether you are playing a single player or multiplayer game. Carmack is an extremely focused and fast programmer that ships games.
It is just soooo easy to look at code and call out its flaws. Would you like to release some of your code online for all of us to scrutinize?
The C version could be optimized as well.
The benchmarks show, by the author's own admission, that the java version runs at about 60% of the C version's speed. That's to be expected, and one must keep in mind that the only part that java slowed was the part that runs on the CPU. All the work that is offloaded to the GPU would not suffer from that drop in speed.
I would like to see performance benchmarks done on an older platform where there is not huge amounts of L1 and L2 instruction caches.
Also, a 40% drop in execution speed is very significant. While Quake2 may run at "only" 200 instead of 300 on a modern machine, if we were looking at a more complex game that was barely making 30 fps on an average machine by today's standards, that 40% drop in performance would be much more noticeable.
I am wary of benchmarks that are done on machines that totally overpower the app they are running.
Actually, on embedded platforms where performance is critical (game consoles, for example), you want absolute control of your memory layout in order to avoid fragmentation. I don't know if you've had experience with memory fragmentation, but it will slow execution down to a crawl. As good as a virtual machine may be about properly organizing memory, it cannot be better than a good programmer with intimate knowledge of his app's mem usage.
You also want execution to be completely deterministic and certainly don't want a garbage collector to be scheduled to run right when you expect it the least and completely trash your cache memory. I know that you can have some degree of control on when your GC kicks in and whether it should try to run in long stints or in regular and sporadic stints, but it's still not 100% control.
On a platform with fixed hardware, if you give up some control and your competitor doesn't, he will have the edge on performance.
It is not until I got to work on high performance embedded software that I finally brutally realized how, in specific cases, having 100% control on the underlying platform will make the difference between good and bad performance. It is not until you reach the limits of a platform that you realize how having full control
Having said this, I agree that a Java app can be plenty fast. However, it is hard to say how fast that java port of quake2 is until you run it on the typical hardware we had when quake2 first came out. If you run the native quake2 and java quake 2 on a PC today, they will both be blazing fast. But I would like to see how the java version performs on a PC that would *just* reach 60 fps for a native quake2. That would be interesting.