Saturday, October 27, 2007
Saturday, October 20, 2007
A fun thing about Episode Two (and Team Fortress 2) is there is a set of "achievements" (or sub-missions); such as breaking every web cache in the caves, killing all the antlion grubs, etc. There is also a fun achievement involving the gnome you find at the very beginning of the game.
The first really tough part was trying to kill two Antlion Guards. You don't have enough ammo (even if you've fully stocked on the shotgun and the MP5) to take them out, so you'll have to be a little creative with explosive barrels and other things you can shoot at them. To make things more fun you have the antlions to worry about too.
The second fun part was the helicopter battle where you desperately try to find a rocket launcher just to realize that there isn't any. The point is to take it out by taking the mines it drops and throw them back at the helicopter. Ah, the joy of crawling around and being shot at by helicopters!
Then there is the Hunters. The first time you encounter them is when Alyx is injured, but the first time you have to take one out is later on when you and Alyx are attacked by a pack of them in a farm house. Also a fun scene, where you have to be a little creative with the gravity gun.
Then there is the final battle. You've reached the White Forest rocket base, but it's being attacked by Striders. And not one, two, or three, but at least 8 or 9. I didn't keep count. This is where the real fun begins. And to make it even more challenging, each Strider is escorted by 2 or even 3 Hunters.
This game is nothing less than a masterpiece. And you haven't really played it until you've played it with the difficulty set to "hard".
Thursday, October 11, 2007
I tried to get some hard details about what they're actually doing, but details are scarce, and any information I could get hold of is full of market-speak. Things like the following sounds like something Dilbert's boss would say:
"Given that everything is defined in XML creates enormous synergies and unleashes the innate power of XML,"
I'm not sure why they push XML so hard. XML is an underlying code/data representation, and will not cause any magic to happen by itself. XML may very well be the best choice of a representation, but it is not a silver bullet.
The fact that all applications are written in XML rings a big, fat, warning in my head. We've heard several claims over the last 20 years about new technologies which will render "traditional programming" obsolete, but we're still here writing code in C++, Java, Erlang, Ruby, Python, etc. What's the common denominator of the 20 most popular programming languages today? Their source code is written using text editors. Yes, some text-editors are most advanced than others, but we're still writing code. Practical, general purpose point-and-click programming won't be here for years.
XML is not designed to be human-editable. This forces you to have top-notch graphical editors on top of everthing, and that is not an easy task. Many have tried and failed (the Eclipse plugin.xml editor is a good example; it is not a bad editor, but it doesn't scale very well for non-trivial XML).
But then again, if Xcerion can deliver on their promises and replace the traditional desktop OS with a system which is light-weight, fast, runs everywhere, and fun to program (sort of like on the old Amiga days), I'm all for it. But I can't help but feeling sceptical about the whole thing.
Xcerion, please prove me wrong.
Thursday, October 4, 2007
The lesson here is: there is always something to do in San Andreas.
Eclipse/CDT is very flexible when it comes to supporting other kind of toolchains; anything which can be broken down to a series of external programs which which interact to produce output from a given set of inputs. You can implement a toolchain for creating PDF files from LaTeX input, although this has little to do with C/C++ development. This great flexibility is actually the first warning flag. Yes, flexibility is a good thing, but the user's have to be able to wield it as well.
Most of the toolchain is defined in the plugin.xml. This is where all tools, configuration, projects type, options, etc. are defined. This is actually the second warning flag. My plugin.xml is at 2000 lines and counting, and I haven't really done anything complicated. A bunch of options, two different project types, two build configurations, and 4 tools (c-compiler, c++-compiler, linker, assembler). Yes, I could probably break out much of this in separate plugins, but that seems a little overkill.
CDT has a system for inheritance among elements in the toolchain definition file. I can define a common base class for my C and C++ compilers, and define C++-specific options in a subclass. What CDT does is basically to paste a primitive inheritance system on top of XML. It works like this:
This may sound great at a first look, but it quickly turns out to be hopelessly inadequate. It's ok to do small things this way, but when you have three different tools with similar set of options you need a way to be able to share these in a more flexible manner.
One of my favorite programming principles is DRY: Don't Repeat Yourself. While writing CDT toolchain definitions you have to break this rule so many times, it's almost physically painful. For example: each XML element has to have a globally unique identifier, and it has to be specified in full in the element itself. In the plugin.xml file which contains my toolchain definition, 25% of the lines includes the reverse-DNS name ("com.foo.bar.plugin", for example) used to make sure that the identifier are globally unique.
There is an option for my compiler which takes 20-30 enumerable values (the target cpu type). To specify this, I have to write an XML element for each of these values:
Instead of allowing me to have a simple list of all cpu types and generate each option, I have to manually (cut-n-paste) expand the enumeration value definitions.
I think it would be better to write the toolchain definition in Java instead. The idea of defining things in the plugin's plugin.xml file is to let Eclipse know things about plugins without having to load the plugin itself, but does this include details about which options my compiler takes? If plugin.xml just defined the entry point classes for my toolchain in the plugin.xml file, I could define the toolchain by creating the appropriate Java objects. This would allow me to use the full power of Java's inheritance system and I can store option metadata (such as the number of available cpu types) in a way most suitable for my needs.
Monday, October 1, 2007
airs here in Sweden on TV4 twice a week), and I must say that it is
the most intriguing TV-series I've watched since the first season of
24. The combination of a compelling story arc and superheroes (without
tights!) makes for very enjoyable TV, especially when most other
programs are some form of reality-tv (home makeover shows, American
Idol (or the swedish equivalent), etc.) which I really can't stand.
And I like the more or less subtle references to Star Trek (there are
more than just Hiro doing the Vulcan salute).