A couple of months ago I discovered Pyglet, which is basically an OpenGL interface for Python. I experimented with it, figuring out different features. I had never really worked with OpenGL before, and the little bit of experience I had was limited to translating GLUT spheres (for an N-body simulation for my Parallel Computing class).

Screenshot of my program (image link broken)

My exploration into Pyglet was a two-pronged attack. On the one hand, I had to learn how to use OpenGL, and on the other I had to learn Pyglet’s idiosyncratic diversions from standard C OpenGL. Fortunately, there is a wealth of tutorials and explanations on the Internet regarding OpenGL, and Pyglet is fairly well documented.

However, there is a caveat to exploring a new tool: debugging becomes much harder. When your code stops doing what it is supposed to, you have no idea whether the bug stems from a mistake in your code, or a fundamental error in your method. Moreover, your method may work in theory, but you are using the new API incorrectly. Since there is no way to test all three of these possibilities at once, you have to assume two of them are correct and look for an error in the third. If you pick wrong, you can spend days looking for a bug in the wrong place.

For instance, I was writing code to find the ray originating from the camera and passing through a point on the screen where the user had clicked. The issue here is that although you know the location of the click with relation to the window, you don’t know where it is in world space. Well, I went through 3 or 4 methods for finding the vectors in world space that corresponded to the vertical and horizontal directions on the screen. After that the problem becomes trivial.

A graphic description of my problem

In desperation I started printing out random things in the body of my code. I realized that two variables which should have been the same were very different. It turned out that when I found the location of user click in world space (which was stored as a vector), I was accidentally normalizing it.

I had assumed my code had no careless errors, and had instead blamed the bug on my method. In reality, I doubt there was ever a problem with my method. Instead, the problem had always lain in the three lines of code that I considered the “trivial” part of the problem. While it was quite trivial, that triviality also protected it from proofreading. After wasting a good 4 or 5 days on the problem, I have learned my lesson: there was absolutely nothing I could have done about it.

Crysis 3: First Impressions

I put my beefy new graphics card up to the test. I’ve always been a fan of Crysis. The first Crysis game was such a brilliant creation. From the spine-singling intro scenes, to the best mix of cutscenes and free-roam arenas. The vehicles, guns, and explosions all felt right. But the game kept getting better. The tank battle was a nice departure from the jungle stealth of the start. Then the zero gravity sequence just totally blew my mind. That turned Crysis into delicious cake. The ice level, the VTOL sequence, and the entire last level (with that epic end sequence) were all just frosting.

Crysis Screenshot

I know every level of that game by heart. So when Crysis 2 came out, I was excited. The multiplayer beta gave me some idea of how the controls would differ. But I reserved judgement (since the singleplayer campaign is the heart of any game). So imagine my surprise and disappointment when the game came out, and it sucked. Gameplay was boring and linear, enemies were samey and uninteresting, vehicle sections were highly linear, and the graphics were somehow worse than the first game. Despite all the hype over the “CryEngine 3”, the graphics were plasticy and bloomy. Crytek took everything interesting out of the series, and removed all the main characters to boot – Nomad was replaced by a silent, unimpressive protagonist. The game was cut and dried; there was no boisterous spirit left in the IP.

Since Crysis 3 came out, and I got a new graphics card, I figured I would buy the game. Maybe Crytek had taken the lessons they learned in making Crysis 2 to heart. Nyeeeh. The enemies and weapons are the same, and the interface is still dumbed down. I’ll admit, the graphics look a bit better, and the choice of environment is sounder. But since when was a bow and arrows cool? The bow and arrow concept seems like a feature tacked on to justify the game; without it, Crysis 3 would just be a short story add-on to Crysis 2.

My biggest issue is that the game is still highly linear. There are such excellent, expansive sets in Crysis 3, but each area is bounded by myriad invisible walls. The crudest element, which really insults me, is that you can see into the void in some places, where they forgot to put geometry. CryEngine has a default feature that puts a terrain layer across the entire map. The fact that they eschewed that, which was designed for creating large free-roam environments, means that Crytek has truly forsaken the idea of open gameplay. This makes me sad. There was great opportunity for this urban grassland idea. Imagine being able to fight through semi-collapsed buildings, then onto a grass plain, then climb onto a freeway and drive a tank down it, scaring deer out of the way and shooting down helicopters, which crash into skyscrapers.

There were good things about Crysis 2 and 3. The idea that the nano-suit is alien technology, the idea of Prophet’s conscious switching bodies. The stalkers in high grass were cool. But they screwed up the aliens, didn’t bring back ice levels or zero gravity, and took away speed and strength mode, tactical nuke launchers, and in-game freedom. I will continue to tout the demise of the Crysis franchise as a definitive argument against EA and consoles.

< / rant >


Honestly I’m not sure who thought it was good idea to make this language. I’ll admit its better than PHP, and I understand that some people actually enjoy using it. For instance, there is a web server written completely in JavaScript (hence my comparison to PHP). This boggles my mind.

My main issue with it is that there are no high level features built inherently into the language. For instance, there isn’t even an agreed upon method for importing other JavaScript files. Inheritance? Going to do some pretty messy hacks in order to get something that acts like an inheriting class structure. How about maps (aka dictionaries)? Objects and maps are the same thing. Arrays are basically just hash-maps for non-negative integers.

I suppose it’s about interesting exercise in thinking. Treating every structure (including classes and functions) as variables had its upsides. Ultimately, though, you have to use it whether you like it or not. There’s no substitute for the client-side functionality it provides. CSS can only go so far. When you start looking at something like AJAX, it makes you cry simultaneously at the pain of working with it and in joy for all the opportunity it provides.

The reason I have been thinking about and working with JavaScript (although only dabbling, of course) is that I’ve been taking another course at Udacity. This one is on game development in HTML5. Before this course, I really had no idea what HTML5 was. I had heard it mentioned, but then it all blew over. HTML5 is, to the best of my understanding, a standard that introduces some new HTML elements and JavaScript standards that lets developers manipulate pages in more creative ways.

For closing thoughts, I’ll leave you with this hilarious “talk”:

%d bloggers like this: