I want "player" cities to be as far apart as possible. Neutral cities I care less about. For the common cases it's quite easy but let's say there's only one continent well then I want to place the cities with maximum space between them. I have an idea it's just getting myself to implement it. Today I don't think I'll be doing any work anyway. Schools busy at the moment as it's the end of the school year in Japan soon - so less programming time.
Anyway books:
The Pragmatic Programmer
By: Andrew Hunt, David Thomas
This is an excellent book on programming in general. There's a bit of an object / procedural bias which is perfectly understandable given that's what languages in general use today. The book addresses what exactly is meant by terms such "modular" and "flexible" and how such properties can be achieved. There are plain, well explained examples showing how to keep code clean and clear.
They also recommend the use of emacs or vi for all editing. The arguments seems pretty solid, only one set of commands to learn, language agnostic, works even without a graphical interface but I don't agree. I've used vi (though I admit not emacs) and I think the problem is they're text based and they're text editors. I want something that edits a programming language, currently the best editor has to be Visual Studio (or one of it's clones). I like C# so I'm quite bias. It's a graphical system, when coding you can see the tree of your project over on the side so you have an overall idea of the architecture.
Debugging
Debugging is built in. If the programs crashing, then with a click you can put in halt points marked in red. So when execution hits this point - it's paused and the code is displayed on your screen. By waving the mouse over the variables on the screen you are informed of their current values. If the variables are classes you can open them up and look at all the inner values without problem. And that's anywhere on the screen. As I said, I'm not familiar with emacs but vim doesn't have this type of debugging facility, infact I can't imagine that it could be achieved so intuitively in a text only program.
Not only that but you can change the code during execution. That's a benefit of the IDE being strongly coupled to the language.
If your code fails to compile, an error message appears, clicking on the error takes you to the exact place in the code where the problem is occuring.
Intellisense
This is avaliable in emacs and vim but not natively - you'd have to fiddle around with scripts or write one yourself (and it's never going to be as good if I> make it because I'll be tempted to leave out rarely used parts of the language). The VS IDE uses reflection to pick up the details of the classes you're using, then it creates a text box that guesses what you might be typing. If you press tab, it auto-completes the word (you can bring this up at any time with Control-Space). In a text-based system you cannot have that floating text box, you also cannot have pictures that represent what each option represents - a class, private or protected variable etc.
In-built Refactoring Tools
These two are great, I love the rename one alone. I know VI can be programmed to do such things but I don't want to spend time programming my programming tool - I just want to use it. Also such programming would be an extreme undertaking. Selecting areas of code and having them changed into a method automatically, by using Extract Method, is a godsend. Though the one I use most is probably rename - it's changes a ill-thought out name in a snap and it changes it throughout your program.
The future is a graphical IDE. (check out there flash movies)
Well, that turned into quite the rant, but other than that point - I agree and I think the book is excellent and important. (Though the actual book binding kind of sucks.)
Twisty Little Passages, An Approach To Interactive Fiction
By: Nick Montfort
A book about the history of text games. It's stressed that the term interactive fiction is more appropiate and should be used, but I think "text game" is more commonly understood and that's why I use it here. It covers the history of text games starting from riddles to Adventure, the first text game, then through the brief commercial period and finally to the current period of indie-ness. The history is interesting, though I feel a bit too much time is given to Zork and dicussion or analysis of Zork, like it was some long-thought-out master piece. There's too much overanalysis in general for my tastes - I'm not saying one shouldn't examine interactive fiction, like you might examine literature, rather that this isn't the place. It all seems to much of plea for "serious literate types" (whoever they may be) to appreciate this art-form. An issue I doubt many readers feel strongly about. But that is the focus of this book.
Apart from that it's an interesting read. There's a lot about the more obscure text games, that are trying something new. There's also a brief dicussion about puzzles and what makes a puzzle good. I would have liked more about this but once again maybe this isn't the book.
The really interesting text games are those that do some modelling of NPCs using chatterbots. But these are only mentioned in passing and it's hard to ascern how succesful the implementors have been. As the whole text games / art debate, I see no reason why a text game couldn't equal the importance of a linear book, though I think the parser improving by a factor of ten or so might help. (Try Rameses (bottom of the page) if you want to try a game that's a bit different.)
Given what I know now, I probably wouldn't buy this book. There's too much of "this is why text games are actually art" and not enough of "these games are extremely innotative and interesting" or "these puzzles are interesting for the following reasons". It's a well written and well researched book, those interested in text games would probably enjoy it a lot.
No comments:
Post a Comment