I think you might be missing the point. It's not about completely automating the task of software development, such that it is like a manufacturing process.
It's about applying process so that you have a foundation from which to be creative.
Let me give an example: it's hard to creatively solve development problems when the gun is to your head to fix bugs that should have been caught earlier, because your organization has no process.
I've worked at large corporations without process. Every success is unrepeatably (that is, luck). And failures abound. For example, if I spend all weekend cleaning up a design that failed because requirements were wrong, and the process didn't check those requirements, I regard that as failure. Not of myself, or even the requirements engineer, but of the process and organization itself.
Perhaps you have not had the misfortune of working in such a place?
Well, they do make a big deal of saying each iteration goes through the workflows and produces an increment, and there are multiple iterations per phase.
In their scheme, it appears that requirements, analysis, and design differ more by level and intent than by content. So in that scheme, each can be viewed as a refinement of the previous. At least, that's my interpretation. I Am Not A Methodologist.:-)
They do say that, for example, that you might analyze 5% of the use-case mass in the inception phase, 20-40% in the elaboration phase, etc. So you're always going back to flesh out more detail at a later phase, if I understand correctly.
I don't recall them speaking too much about code generation. It's not in the index. I'd expect them to recommend it, but it's not a big topic in the book. As always, take with salt.:-)
XP does have some interesting ideas. There is a book coming out soon by Beck et al. I'll probably end up getting it, although perhaps not all in the coming series.
I would argue that all programs should have those qualities.
See Jon Bentley's "Programming Pearls" for details.
Sure, you can have an application that is a mere "tool" but if everything comes together, you have an elegant "pearl", whether it is a game or an FTP client or backup software or whatever.
I just browsed the student projects. It looks like they have to produce storyboards, screen mockups, state machines, flow charts, game stories, etc.
How is that different than any programmer producing screen mockups and UML diagrams? Or, writers producing plot outlines and draft chapters.
Or, is the intent to provide extremely focussed training (like community college) that also yields a portfolio when finished (like a fine arts student)?
First of all, AI is such a general term that it's hard to apply it realistically. Anything that helps the machine to appear intelligent, or to learn (not the same thing), can be considered AI.
In that respect, pathfinding is a form of AI because it does involve choosing an "intelligent" path from one point to another. Yet obviously a computer opponent that can outthink you and learn from your actions exhibits even more "intelligence".
Second, I don't necessarily have a problem with AI "cheating", if it is done subtly enough. The human player obviously has many advantages compared to the computer player. I'm prepared to balance that out a little if need be. In particular, it may be that AI methods that don't cheat are ideal, but are sacrificed because we don't have the computational power (CPU etc.) to execute them. In the end, the question is whether the game play experience is enjoyable or not. If the AI had to "cheat" a little behind the scenes to achieve that, I'm okay, so long as it isn't obvious.
Next, you have to realize that although AI methods have had some success, often it is in specialized areas, such as expert systems. The problem of building a general AI opponent is a little more like a Turing test that identifying a tumour.
Typically classical AI methods are rule based and procedural. The tendency in the last decade or two has been toward emergent behaviours, under the umbrella of artificial life techniques.
There are a host of techniques the developer can employ to do AI, but some are hard to implement (or implement well). Some require tweaking to achieve good results. Typically memory is required to store state, so that intelligent decisions can be made.
In my game, I am hoping to finish my unit grouping and action classes soon. After that, I'll either work on networking or more complex actions. I intend to build a goal-based action structure for my computer opponents. For example, a high level goal might be "occupy quadrant 4" with subgoals of "eliminate enemy base 3" and "fortify ridge in sector 7".
There's nothing new there, that sort of stuff has been written about since Minsky and friends. But obviously the implementation leaves a lot of room for creativity, because I haven't seen it pulled off very well.
In my AI course I created a simulation of autonomous agents on a little lattice. Their goal was to wander around, eat bushes, and avoid predators.
Each was controlled by a little neural network. They had inputs such as their health, energy, what's in the eight squares around them, etc.
They would make their decision and do it. Then another function would evaluate what they did and determine if it was "good." For example, if they lost health, that was "bad."
Then I'd do a little weight update on the ANN to reflect that action. This made for incremental learning.
For example, if the agent was on food (input) and ate (output), that increased its energy (good) so that was slightly reinforced for next time.
I never really got to play with it much, so I'm not surprised they really didn't seem to get better over time. I think they died too early to really learn. My simulation had flaws. I know a lot more now and am sure I could pull it off, given time.
I may use methods like that in my RTS game (see URL).
I was just about to mention the Burroughs connection. Those novels had really strange ideas of information as virus, propagating through human (and non-human) minds.
Philip K. Dick also had similar ideas, expressed in his exegis and novels such as VALIS and Radio Free Albemuth.
If you really want a Linux game project to work on, or just some source to hack on, my RTS projects page lists many open source efforts. I'm sure some of them can use a helping hand.
http://www.cgocable.net/~mlepage/rts/projects.ht ml
I'm working on my own Linux game right this minute, re-vamping the view hierarchy. How come I don't get Slashdot articles devoted to Minion?
Unfortunately I don't have the book with me at the moment. The author is pretty fixated on performance, to the point where I would say it impedes with the pedagogical objectives of the book. In short, I want a book that teaches me (effectively) how to program RTS games. The examples need not be "the fastest possible" or indeed even "production performance class." That would typically interfere with the ability of the reader to learn from the book.
The author can note that such code may not be fast enough for a production game, but explain the concepts used to rectify that, and leave the performance tuning as an exercise. I have enough books on efficient design and tuning code already.
I don't need pages devoted to an assembly implementation or a "really clever implementation."
I think if you follow the advice (mostly from Stroustrup and Meyers) at http://www.ses.com/~clarke/cpptips/perf_eff_opt then you can't go wrong.
A similar pedagogical issue is all this "roll your own" container madness. I'd rather the book used the STL throughout, *even* if it were not suitable for a production version of the game (which I haven't had demonstrated to me yet). Then the author wouldn't have to introduce and explain his own containers and their usage: he could refer the "intermediate to advanced" reader to a good STL book. At least the STL is Standard.
Your interpretation is correct. By all means provide your own memory management if necessary. Meyers and Stroustrup each provide a wealth of material on how to do it properly. And that way is to customize the new/delete operators. That's what they are there for.
And you are correct, not everyone has to agree with my review.:-)
I've made some comments in the threads. Some elaborate on points in the review, while others introduce other points I had forgotten to include in the review itself.
The need for a good RTS game programming resource is clear. I have a web site devoted to that goal at http://www.cgocable.net/~mlepage/rts/
I am *not* a professional game developer, though I *am* a professional developer. I am learning some of these game programming techniques from first principles, so in some ways I am far behind current technology (eg Age of Empires) but in others I am ahead (eg sound application of design patterns).
Since my free time is divided between reading books, working on my game, and documenting on my web site, among non-computer-related pursuits, the work is slow. But check it out if you're interested in RTS game programming.
That was one thing I forgot to mention in the review. The author says to get used to 80-hour weeks because that will happen for sure, and it is the only way to make a professional game. (paraphrased)
McConnell is clear in Code Complete about such bullshit gonzo attitude.
Maybe that's how the "primitives" do software development but I already quit one major software company because of that sort of perpetual "Red Queen" environment.
The "gurus" know better, it's not like this stuff hasn't been written about since Brooks wrote The Mythical Man-Month.
I have no problem with a game programming book being exclusively focused on DirectX, even if I don't use it personally. As I pointed out, I could always port such platform-dependent usage to a comparable API, such as OpenGL, if I wished. Or, I could just use the concepts expressed.
However, a game programming book must be about game programming first.
This book promised "RTS Game Programming *using* DirextX" but delivered several chapters just on DirectX.
As a comparison, consider "Concurrent Programming in Java" which I previously reviewed. It is a book on concurrent programming which just happens to use Java as its implementation example language. It is *not* a book on Java programming.
That is what I was expecting. Perhaps I was misled by the term "using" in the book's title.
Don't get me wrong, I am interested in game design. I just expected a book more devoted to the *construction* of RTS games. As you pointed out, there are already several resources (eg, Game Developer post mortems) on the design of RTS games. But few on their construction.
I am already fairly skilled at program design in general (patterns, architecture, etc.), and am in fact currently designing some systems at work in addition to my game at home.
Design is incredibly important. But this book claims to be about "programming" which I believe is generally considered to mean lower-level implementation as opposed to "design", "analysis", etc.
You are exactly correct. I write reviews for Slashdot as well, and if I generally give good reviews, it is because I read good books.
For me to invest my own time a) reading a poor book to completion, and b) writing a review of that poor book, I would have to be extremely motivated.
I put a lot of effort and thought into my reviews. They are predominantly about computer programming books, because that is what I read and that is what I do. I like to think that others appreciate that effort and thought.
Oh, by the way, I am about to write a bad review, hopefully finish it tonight. It does happen.:-)
Slashdot Mirror
I think you might be missing the point. It's not about completely automating the task of software development, such that it is like a manufacturing process.
It's about applying process so that you have a foundation from which to be creative.
Let me give an example: it's hard to creatively solve development problems when the gun is to your head to fix bugs that should have been caught earlier, because your organization has no process.
I've worked at large corporations without process. Every success is unrepeatably (that is, luck). And failures abound. For example, if I spend all weekend cleaning up a design that failed because requirements were wrong, and the process didn't check those requirements, I regard that as failure. Not of myself, or even the requirements engineer, but of the process and organization itself.
Perhaps you have not had the misfortune of working in such a place?
Well, they do make a big deal of saying each iteration goes through the workflows and produces an increment, and there are multiple iterations per phase.
:-)
:-)
In their scheme, it appears that requirements, analysis, and design differ more by level and intent than by content. So in that scheme, each can be viewed as a refinement of the previous. At least, that's my interpretation. I Am Not A Methodologist.
They do say that, for example, that you might analyze 5% of the use-case mass in the inception phase, 20-40% in the elaboration phase, etc. So you're always going back to flesh out more detail at a later phase, if I understand correctly.
I don't recall them speaking too much about code generation. It's not in the index. I'd expect them to recommend it, but it's not a big topic in the book. As always, take with salt.
I haven't yet read Booch's book (I got it recently), and it's been years since I read half of Rumbaugh's book, so I can't remember it.
But I also find that to be a flaw. Everyone can say "rectangle" is an object in a drawing program derived from "shape", but what about harder domains?
XP does have some interesting ideas. There is a book coming out soon by Beck et al. I'll probably end up getting it, although perhaps not all in the coming series.
I would argue that all programs should have those qualities.
See Jon Bentley's "Programming Pearls" for details.
Sure, you can have an application that is a mere "tool" but if everything comes together, you have an elegant "pearl", whether it is a game or an FTP client or backup software or whatever.
I just browsed the student projects. It looks like they have to produce storyboards, screen mockups, state machines, flow charts, game stories, etc.
How is that different than any programmer producing screen mockups and UML diagrams? Or, writers producing plot outlines and draft chapters.
Or, is the intent to provide extremely focussed training (like community college) that also yields a portfolio when finished (like a fine arts student)?
First of all, AI is such a general term that it's hard to apply it realistically. Anything that helps the machine to appear intelligent, or to learn (not the same thing), can be considered AI.
In that respect, pathfinding is a form of AI because it does involve choosing an "intelligent" path from one point to another. Yet obviously a computer opponent that can outthink you and learn from your actions exhibits even more "intelligence".
Second, I don't necessarily have a problem with AI "cheating", if it is done subtly enough. The human player obviously has many advantages compared to the computer player. I'm prepared to balance that out a little if need be. In particular, it may be that AI methods that don't cheat are ideal, but are sacrificed because we don't have the computational power (CPU etc.) to execute them. In the end, the question is whether the game play experience is enjoyable or not. If the AI had to "cheat" a little behind the scenes to achieve that, I'm okay, so long as it isn't obvious.
Next, you have to realize that although AI methods have had some success, often it is in specialized areas, such as expert systems. The problem of building a general AI opponent is a little more like a Turing test that identifying a tumour.
Typically classical AI methods are rule based and procedural. The tendency in the last decade or two has been toward emergent behaviours, under the umbrella of artificial life techniques.
There are a host of techniques the developer can employ to do AI, but some are hard to implement (or implement well). Some require tweaking to achieve good results. Typically memory is required to store state, so that intelligent decisions can be made.
In my game, I am hoping to finish my unit grouping and action classes soon. After that, I'll either work on networking or more complex actions. I intend to build a goal-based action structure for my computer opponents. For example, a high level goal might be "occupy quadrant 4" with subgoals of "eliminate enemy base 3" and "fortify ridge in sector 7".
There's nothing new there, that sort of stuff has been written about since Minsky and friends. But obviously the implementation leaves a lot of room for creativity, because I haven't seen it pulled off very well.
In my AI course I created a simulation of autonomous agents on a little lattice. Their goal was to wander around, eat bushes, and avoid predators.
Each was controlled by a little neural network. They had inputs such as their health, energy, what's in the eight squares around them, etc.
They would make their decision and do it. Then another function would evaluate what they did and determine if it was "good." For example, if they lost health, that was "bad."
Then I'd do a little weight update on the ANN to reflect that action. This made for incremental learning.
For example, if the agent was on food (input) and ate (output), that increased its energy (good) so that was slightly reinforced for next time.
I never really got to play with it much, so I'm not surprised they really didn't seem to get better over time. I think they died too early to really learn. My simulation had flaws. I know a lot more now and am sure I could pull it off, given time.
I may use methods like that in my RTS game (see URL).
It's worth noting that G, A, T, and C are the four symbols in your DNA.
There is no I.
I was just about to mention the Burroughs connection. Those novels had really strange ideas of information as virus, propagating through human (and non-human) minds.
Philip K. Dick also had similar ideas, expressed in his exegis and novels such as VALIS and Radio Free Albemuth.
Hm, I was just reading about Hillis' work in a genetic algorithms book when this was posted. Talk about coincidence.
The article also mentions Dawkins. I've been doing some alife reading lately and they're both in there.
Of course virii/worms have great alife analogies.
If you really want a Linux game project to work on, or just some source to hack on, my RTS projects page lists many open source efforts. I'm sure some of them can use a helping hand.
t ml
http://www.cgocable.net/~mlepage/rts/projects.h
I'm working on my own Linux game right this minute, re-vamping the view hierarchy. How come I don't get Slashdot articles devoted to Minion?
Leave the troll. It obviously never even read the review.
Actually there are links to several more RTS projects for Linux on my web page.
What exactly is Windows-specific about my review?
I reviewed the book. I am a Linux programmer. I am making a Linux RTS game at home. I program on Linux at work.
I don't understand.
Unfortunately I don't have the book with me at the moment. The author is pretty fixated on performance, to the point where I would say it impedes with the pedagogical objectives of the book. In short, I want a book that teaches me (effectively) how to program RTS games. The examples need not be "the fastest possible" or indeed even "production performance class." That would typically interfere with the ability of the reader to learn from the book.
The author can note that such code may not be fast enough for a production game, but explain the concepts used to rectify that, and leave the performance tuning as an exercise. I have enough books on efficient design and tuning code already.
I don't need pages devoted to an assembly implementation or a "really clever implementation."
I think if you follow the advice (mostly from Stroustrup and Meyers) at http://www.ses.com/~clarke/cpptips/perf_eff_opt then you can't go wrong.
A similar pedagogical issue is all this "roll your own" container madness. I'd rather the book used the STL throughout, *even* if it were not suitable for a production version of the game (which I haven't had demonstrated to me yet). Then the author wouldn't have to introduce and explain his own containers and their usage: he could refer the "intermediate to advanced" reader to a good STL book. At least the STL is Standard.
I'm glad you enjoyed the review.
:-)
Your interpretation is correct. By all means provide your own memory management if necessary. Meyers and Stroustrup each provide a wealth of material on how to do it properly. And that way is to customize the new/delete operators. That's what they are there for.
And you are correct, not everyone has to agree with my review.
I've made some comments in the threads. Some elaborate on points in the review, while others introduce other points I had forgotten to include in the review itself.
The need for a good RTS game programming resource is clear. I have a web site devoted to that goal at http://www.cgocable.net/~mlepage/rts/
I am *not* a professional game developer, though I *am* a professional developer. I am learning some of these game programming techniques from first principles, so in some ways I am far behind current technology (eg Age of Empires) but in others I am ahead (eg sound application of design patterns).
Since my free time is divided between reading books, working on my game, and documenting on my web site, among non-computer-related pursuits, the work is slow. But check it out if you're interested in RTS game programming.
That was one thing I forgot to mention in the review. The author says to get used to 80-hour weeks because that will happen for sure, and it is the only way to make a professional game. (paraphrased)
McConnell is clear in Code Complete about such bullshit gonzo attitude.
Maybe that's how the "primitives" do software development but I already quit one major software company because of that sort of perpetual "Red Queen" environment.
The "gurus" know better, it's not like this stuff hasn't been written about since Brooks wrote The Mythical Man-Month.
I beg to differ.
I have no problem with a game programming book being exclusively focused on DirectX, even if I don't use it personally. As I pointed out, I could always port such platform-dependent usage to a comparable API, such as OpenGL, if I wished. Or, I could just use the concepts expressed.
However, a game programming book must be about game programming first.
This book promised "RTS Game Programming *using* DirextX" but delivered several chapters just on DirectX.
As a comparison, consider "Concurrent Programming in Java" which I previously reviewed. It is a book on concurrent programming which just happens to use Java as its implementation example language. It is *not* a book on Java programming.
That is what I was expecting. Perhaps I was misled by the term "using" in the book's title.
I think my point is valid.
No, thank you. I worked hard on that review and it is nice that it is appreciated.
Don't get me wrong, I am interested in game design. I just expected a book more devoted to the *construction* of RTS games. As you pointed out, there are already several resources (eg, Game Developer post mortems) on the design of RTS games. But few on their construction.
I am already fairly skilled at program design in general (patterns, architecture, etc.), and am in fact currently designing some systems at work in addition to my game at home.
Design is incredibly important. But this book claims to be about "programming" which I believe is generally considered to mean lower-level implementation as opposed to "design", "analysis", etc.
I have both UNIX and Linux in a nutshell. My UNIX is dated August 1994.
To be honest I've rarely used them. I usually find the installed man pages more up to date, and enjoy being able to search for a command option.
But I have them nonetheless.
You are exactly correct. I write reviews for Slashdot as well, and if I generally give good reviews, it is because I read good books.
:-)
For me to invest my own time a) reading a poor book to completion, and b) writing a review of that poor book, I would have to be extremely motivated.
I put a lot of effort and thought into my reviews. They are predominantly about computer programming books, because that is what I read and that is what I do. I like to think that others appreciate that effort and thought.
Oh, by the way, I am about to write a bad review, hopefully finish it tonight. It does happen.
My copy of Joseph Campbell's seminal work "Hero With A Thousand Faces" has, amid pics of gods and myths, a Star Wars pic on the cover.