DayZ update

It looks like the developer of DayZ is doing all the right things. Latest update notes:

* This is a pretty major update. I don't really know what affect the new sickness and temperature system will have on player behavior especially with antibiotics being so scarce.
* It is the genesis of an idea, so please remember this might cause havoc. You need to be careful.
* To light a fire, you need matches and wood in your inventory. Place more wood in the inventory of a fireplace to keep the fire going.
* A fire that does not have wood in it will go out when you try to light it.
* You can tell you have an infection, because your character will start coughing. The infection causes you to loose blood down to a minimum of 6000. This leaves you with reduced blood until you take antibiotics.

---

Here you can clearly see the beginnings of a Minecraft like play. If done right - without the missteps that Minecraft took - could be really good.

How to write software

A friend from my previous job sent me the below a couple of days ago. These suggestions fit perfectly with the exact opposite approach to what we were taking on the project I was working on there. It looks like things are changing.

It's all straight-forward stuff. If you work in enterprise software development, you already know how often these ideas are not followed.

---

Code Smells Within Classes

·         Comments: There's a fine line between comments that illuminate and comments that obscure. Are the comments necessary? Do they explain "why" and not "what"? Can you refactor the code so the comments aren't required? And remember, you're writing comments for people, not machines.

·         Long Method: All other things being equal, a shorter method is easier to read, easier to understand, and easier to troubleshoot. Refactor long methods into smaller methods if you can.

·         Long Parameter List: The more parameters a method has, the more complex it is. Limit the number of parameters you need in a given method, or use an object to combine the parameters.

·         Duplicated Code: Duplicated code is the bane of software development. Stamp out duplication whenever possible. You should always be on the lookout for more subtle cases of near-duplication, too. Don't Repeat Yourself!

·         Conditional Complexity: Watch out for large conditional logic blocks, particularly blocks that tend to grow larger or change significantly over time. Consider alternative object-oriented approaches such as decorator, strategy, or state.

·         Combinitorial Explosion: You have lots of code that does almost the same thing... but with tiny variations in data or behavior. This can be difficult to refactor-- perhaps using generics or an interpreter?

·         Large Class: Large classes, like long methods, are difficult to read, understand, and troubleshoot. Does the class contain too many responsibilities? Can the large class be restructured or broken into smaller classes?

·         Type Embedded in Name: Avoid placing types in method names; it's not only redundant, but it forces you to change the name if the type changes.

·         Uncommunicative Name: Does the name of the method succinctly describe what that method does? Could you read the method's name to another developer and have them explain to you what it does? If not, rename it or rewrite it.

·         Inconsistent Names: Pick a set of standard terminology and stick to it throughout your methods. For example, if you have Open(), you should probably have Close().

·         Dead Code: Ruthlessly delete code that isn't being used. That's why we have source control systems!

·         Speculative Generality: Write code to solve today's problems, and worry about tomorrow's problems when they actually materialize. Everyone loses in the "what if.." school of design. You (Probably) Aren't Gonna Need It.

·         Oddball Solution: There should only be one way of solving the same problem in your code. If you find an oddball solution, it could be a case of poorly duplicated code-- or it could be an argument for the adapter model, if you really need multiple solutions to the same problem.

·         Temporary Field: Watch out for objects that contain a lot of optional or unnecessary fields. If you're passing an object as a parameter to a method, make sure that you're using all of it and not cherry-picking single fields.

Code Smells Between Classes

·         Alternative Classes with Different Interfaces: If two classes are similar on the inside, but different on the outside, perhaps they can be modified to share a common interface.

·         Primitive Obsession: Don't use a gaggle of primitive data type variables as a poor man's substitute for a class. If your data type is sufficiently complex, write a class to represent it.

·         Data Class: Avoid classes that passively store data. Classes should contain data and methods to operate on that data, too.

·         Data Clumps: If you always see the same data hanging around together, maybe it belongs together. Consider rolling the related data up into a larger class.

·         Refused Bequest: If you inherit from a class, but never use any of the inherited functionality, should you really be using inheritance?

·         Inappropriate Intimacy: Watch out for classes that spend too much time together, or classes that interface in inappropriate ways. Classes should know as little as possible about each other.

·         Indecent Exposure: Beware of classes that unnecessarily expose their internals. Aggressively refactor classes to minimize their public surface. You should have a compelling reason for every item you make public. If you don't, hide it.

·         Feature Envy: Methods that make extensive use of another class may belong in another class. Consider moving this method to the class it is so envious of.

·         Lazy Class: Classes should pull their weight. Every additional class increases the complexity of a project. If you have a class that isn't doing enough to pay for itself, can it be collapsed or combined into another class?

·         Message Chains: Watch out for long sequences of method calls or temporary variables to get routine data. Intermediaries are dependencies in disguise.

·         Middle Man: If a class is delegating all its work, why does it exist? Cut out the middleman. Beware classes that are merely wrappers over other classes or existing functionality in the framework.

·         Divergent Change: If, over time, you make changes to a class that touch completely different parts of the class, it may contain too much unrelated functionality. Consider isolating the parts that changed in another class.

·         Shotgun Surgery: If a change in one class requires cascading changes in several related classes, consider refactoring so that the changes are limited to a single class.

·         Parallel Inheritance Hierarchies: Every time you make a subclass of one class, you must also make a subclass of another. Consider folding the hierarchy into a single class.

·         Incomplete Library Class: We need a method that's missing from the library, but we're unwilling or unable to change the library to include the method. The method ends up tacked on to some other class. If you can't modify the library, consider isolating the method.

·         Solution Sprawl: If it takes five classes to do anything useful, you might have solution sprawl. Consider simplifying and consolidating your design.

DayZ, day 2

Totally different experience today. It was daylight. I found a survivor in a few minutes. We worked together to kill zombies and grab loot off dead survivors. (We didn't kill them!)

After taking-down about seven zombies, I ran out of ammo and had to seek safety on top of a pipe, after climbing a ladder. I lost contact with my buddy. I heard shooting and looked up. Off in the distance, there he was again, taking-down zombies from the top of a tower. They went for him, climbing up the tower. Everything went quiet for a couple of minutes. I couldn't move, still too many zombies to try to risk a run for it. But then my new found friend was back again, in a different spot, drawing the zombies away from me. "Run for it!" he cried.

Why did he care? I was useless. Injured, unarmed, stranded in the middle of a zombie ocean. Yet he helped me anyway.

I ran. I got to a higher place. I was safe for now. I read on the server messages that Cal was dead. I was dismayed. How could I have lasted longer than he did? He had all the gear and the knowledge. I was alone again.

A few minutes later I dropped from a platform. My legs were broken. The zombies feasted on my entrails.

Pictures:

Partner in zombie killing

Site-seeing

The zombies

Safe-zone

Zombies climbing

Death

DayZ

To play DayZ I had to buy Arma 2. After, I followed the installation video-guide on the DayZ download page without a hitch. For mod of a game still in alpha, it was easy to setup.

I started-up DayZ, joined a US server (the Aus and NZ servers were full) and was ready to go.

---

It was night time. Real night time. No moon. I could hear the waves crashing on the beach and see stars in the sky. I heard ominous music. That was it. It looked like this:

Hmm... What was I to do? I tried waiting for daytime (that's what you do in Minecraft.) It didn't work. After about a minute it was as dark as ever.

I looked in the menu options to find the key to turn-on my torch. There didn't seem to be a key for that. I looked in my kit. I had ten flares. I threw one. I went from no light to so much light that I was clearly a sitting duck. Having read about zombies and bandits, I was concerned. I tried pressing all the keys on the keyboard to find the key that would turn-on my torch. I didn't find the key for "torch." Hmm... That's unusual.

I picked up the flare. I dropped the flare. I picked up the flare. Was I suppose to walk around with a flare in my hand like a complete chump? There didn't seem to be any other option. I couldn't see a thing without a flare.

Off I went, knowing full well that I'd be dead in about thirty seconds time. I crossed a railway line. I found  a derelict building. See Exhibit B, Derelict Building:

I dropped the flare and went inside the house so I could find a bunch of great stuff I could use. Like a torch. The building was empty. The flare went out.

I threw a flare and picked it up to carry with me. I walked away from the building. The terrain changed from flat to a hill slope. I walked up the hill. The flare went out. "Okay," I thought. "I can deal with this. I'll just walk in the dark. I'll be fine."

I walked in the dark. I saw a building. It was the same building as Exhibit B. Unknowingly, I had double-backed on myself.

Perplexion set in. I couldn't walk in the dark. I didn't want to walk with a flare. What was I to do?

I stumbled back to the railway-line. See Exhibit C, Railway-line:

"Okay," I thought. "I'll walk along the railway line." At least I could still see that in the pitch black. After about a minute, I saw a flare! (It wasn't mine!)

I ran to the other flare. I was really excited. I had been wandering around for about 20 minutes with basically nothing happening. Finally, there were people! I was going to say "hello." Sure, they might kill me, but at least I wouldn't die alone.

I was so close. Then I heard a horrible sound. Oh my God, zombies! It was freaking scary. I didn't know where they were but I knew they were close. I fumbled for my pistol. This was going to be nasty. A zombie charged up on me. I fired away. It went down. Then another came up. I missed and it swiped at me. A few more shots though and it went down and all went quiet.

I decided to crouch-down and move slowly towards the flare. That way no-one would hear me. I'd be like a ninja. After all, there might have been more zombies out there and I was still a long way from the flare. I needed to be careful, the second zombie was almost the death of me.

But crouching is slow. After a minute I still felt like I was a million miles away. I decided to make a dash for it. Surely those two zombies were the last. And if not, I could make it to the light before they caught me. I would be like a cheetah.

I was not like a cheetah. I was a wounded and imprudent sucker. Two more zombies heard me and came for me. This time I was too slow. They knocked me prone and started to feast on my entrails. But it wasn't the zombies that really killed me. What really killed me was my impatience and a fool's hope.

---

My first play of DayZ was confusing, short and ultimately tragic. The only goal I'd had - to reach the flare - was never realised. But I'll be back and I'll have a torch.

2012, the year of the computer game

There are a few good computer games that have come out over the last year, with a bunch more to come. My favourites so far are:

Legend of Grimrock

Such a tight old-school role-playing game. Every component of this game has been thought about. The puzzles, the monsters the characters, the items. There is never enough food. You're always just about to run out of health potions. Monsters are always one step away from killing your characters. You're almost completely lost and confused by the puzzles.

The most freaky moment thus far has been when I was adjusting my character's inventory and an ogre came charging out of the murky black. That was the first time I'd seen an ogre. My party was dead ten seconds later.

There is one aspect to the game that at first seemed tedious. You have to click on a combination of icons every time you want to cast a spell. I eventually realised that this is a way of making the combat more tense. You're trying to remember the combinations and click the icons before you get smashed by something like the guy below.

Unity of Command

As gratifying as Legend of Grimrock has been, every moment of my time with Unity of Command has been better. Thus far, it appears to be a perfectly crafted strategy game. You have to look for weak points in the battle line where you break through with tanks and mechanised infantry to either charge through to an objective or surround the enemy. Supply lines have been implemented so simply but so effectively. It's devastating to see the lines cut by a lone enemy unit.

Unity of Command is like chess where you can beat the computer and feel like such a bad-arse as you do it.

Turn 3. The Russian line has been broken.
Russian units have been cut off from their supply.

Turn 4. German tanks charge through to take the scenario objectives.
German infantry deal with the remaining Russian troops that have been overrun.

DayZ

I played this for the first time a moment ago. Wow. It's something pretty special. I'll write up my feelings about the game in the next post. In short, it's a terrifying game. I have no idea if I like it just yet, but I'll definitely play it more.

DayZ at night. The house is lite by one of my flares.

Games still to come

Two sequels to one of my favourite games are being released this year. They are Xenonauts and X-Com. They look like they're going to be very good.

2012 is shaping up to have very different games to the malaise of mediocre to dreadful games that have been around for long time now. Now all I need is Elite 4 (never going to happen) or a new X-Wing game to come out and I'll be set.

Diablo 3

I'm playing Diablo 3 multi-player this evening. It is the first time I've played a Diablo game multi-player. I have fond memories of the original Diablo game from 1997. I played it for hours, though never got close to finishing it. I never played Diablo 2.

I've played Diablo 3 single-player this week. I find it utterly perplexing. There are some astonishing design decisions. They seem so poor and obvious that I realise they can be nothing but deliberate. These are:

• Gold is something you need to pick-up, rather than being instantly added to your inventory. Why oh why?
• There are really special magic items need to be identified before they can be used. This takes a right-click and about 10 seconds. WHAT is the function of this mechanic?! I am completely baffled by this.
• The story seems neither good nor bad but completely antithetical to the sort of game that Diablo 3 attempts to be. In multi-player, especially, I can't see how the story could do anything but get in the way.
• Health orbs drop at such a rate that they are frustratingly difficult to avoid as they work instantly and don't do anything if you're already at full-health. It's as though I'm being punished for not being very good at evading a good thing (that I might have wanted to come back to later).
• Every attack is a special attack. I was completely thrown by this. How do I make a normal attack? You don't. It probably didn't help that I started with a Monk and therefore assumed that he wouldn't be using any weapons at all.
• Aside from the big fat men that explode snakes, none of the monsters have been particularly interesting. I was expecting a lot of funky variations. Maybe they come later. Maybe.

Add to this list issues with lag and DRM. Yet, Diablo 3 isn't a terrible game. I'm not sure that it is fun, but it's compelling enough.

Almost all of the issues and weirdness can be blamed on D&D. Designers need to get beyond D&D. Game rules for RPGs are basically arbitrary. You can come up with whatever you want. D&D had a whole bunch of really dumb stuff that was baffling when played around a table and completely useless when played on a computer. RPGs, computer or otherwise, need to get away from D&D almost completely.