Battlefield 2142 Demo – First Impressions

October 8, 2006

Now that the demo is finally here, I’ve realised how much I missed playing 2142 after the beta closed. Going back to intensity of BF2’s infantry only mode was fun, but I’ve been hankering to assault a Titan again for a few weeks. Not knowing anyone else in the beta also meant that I didn’t get to see how the game played out with the GFH regulars. Now the chance has arrived!

Although I managed to snag the demo installer on Friday evening, a weekend away has meant that I’ve only had chance to briefly fire up the demo. On that basis, here are my first impressions:

The good…

  • The map isn’t Verdun! I was sure that EA/DICE would put the beta map in the demo, but we have a new killing field to explore. Sharp-eyed readers will recognise that the demo map appears to be one that featured in one of the gameplay videos released this year.
  • There are plenty of servers around, and the server browser seems to be up to scratch. In fact, the user interface in general seems to have had all of the glitches that were present at the end of beta ironed out.
  • Map loading and game performance in general seems good. I’m not running on uber-settings at all, but the game looks good and is stutter free.
  • There’s a big, ranting review up on the totalbf2142 forums. This guy doesn’t like that his tank can actually be destroyed by ground defences, or that he can’t man a multi-person vehicle solo and lock out (or kick out) those annoying n00b team-mates. You mean, actual team work might be needed to win? Bring it on!

Could try harder…

  • No ranking or unlocks in the demo! I was hoping to try out some unlocks I hadn’t used in the beta to see if they’re worth going for after release. It would also have been great to be able to see if any changes had been made to any beta favourites. No DICE it seems. There are some rumours around the forums that it may be possible to get field upgrades though.
  • Regular disconnects from the master server are being reported, but EA say they’re on top of it. Given that I (and others) suffered regular disconnects from beta servers I hope this is going to be finally fixed for release.
  • 1280×1024 still missing from the in-game video options. Come on guys, how hard can it be?

Here’s looking forward to some more play-time over the next couple of days to see how the game’s shaped up.


Deleting elements inside each. Bad things ensue.

October 4, 2006

Last week a colleague was telling me about some difficulty he was having convincing someone that a web-browser based expandable tree view of data couldn’t be all that difficult. You know the sort of thing, very similar to a graphical file system explorer where you can expand branches and generally have a good sniff around your hierarchical data set.

It nagged at me the rest of the day. How hard could it be to do? I finally cracked and decided to whip up a quick Rails prototype. 2 hours later and I was done. With test data in my database I could use my browser just like Windows Explorer, expanding branches merrily as I went. All was good. Or so I thought.

On closer inspection, something was wrong. The code that was called when the user wanted to collapse a branch wasn’t working right, any expanded sub-branches remained open. I was holding a list of the expanded branches in the user’s session, and all the code had to do was remove the collapsing branch (and any of its expanded children) from the list.

Here’s the original code (the model is using acts_as_nested_set, which is why the logic to check whether a node is a child of the one being collapsed is coded the way it is):

session[:expanded].each do |party|
  if(collapsed.lft < party.lft && collapsed.rgt > party.rgt)
    session[:expanded].delete party

Hmmm. It seems to be doing the right thing. Old Ruby hands (and those with more switched on brains than me when I wrote this) will already see what took me a long time to find out with breakpoints and irb. As I looked at the code execution at breakpoints I fell into an old, old trap. Using acts_as_nested_set was something new for me, whereas handling arrays was as old as the hills. I managed to convince myself that the problem was in the “if…” logic. There must be an error in it that’s failing to properly identify children of the node being collapsed. It took me a while to finally admit that, no, the logic was right and the error was elsewhere.

As soon as I did that, the answer hit me. I was deleting items from an array while I was iterating over it with each. This is the Ruby equivalent of crossing the streams. Every atom in your body won’t simultaneously explode, but something bad will definitely happen.

It didn’t take long to find an answer, thanks to my new friend delete_if. This handy method takes a block, and deletes all elements of an array for which the block returns true. The balance of the universe is restored, and I can feel happy at learning lots more about debugging Ruby with breakpoints and irb.

Remember, don’t cross the streams!