One of the best games I've played on a long time, I thought Dishonored was a truly outstanding game.
While the plot was fairly predictable, the fantastic setting and outstanding voice acting made the whole game feel truly big-budget.
Similarly, the open-world approach to the missions and the imaginative range of special powers made for an atmospheric blend of tension and sudden violence that was great fun from start to finish.
One criticism that I've seen levelled at Dishonored is that it's too short. I find that a bit strange - maybe if you blitzed through it with crossbows blazing you could finish pretty quickly, but that would be missing the point.
I played with a mostly-stealth approach, but without going for the extreme pacifist achievements and I clocked around 24 hours over a week - collecting most items without being a completionist.
I guess I'm lucky that I can afford to buy new games fairly regularly - but I would much rather play a short, perfectly formed, game than something padded out just to make it longer (looking at you, Skyrim)
And 24 hours isn't exactly short.
So if you're worried about value for money, don't be. If you're not a fan of stealth games, neither am I - Dishonored is definitely worth playing (although it might be worth waiting for the next Steam sale as it was 50% off at Christmas...)
Monday, 7 January 2013
Monday, 31 December 2012
Black Mesa
I really wanted to like Black Mesa. I mean, it's an indie rebuild of Half-Life on the Source engine - what's not to like? How could I possible not like it?
Weeeell, it was OK. Certainly there was nothing wrong with it and as a technical accomplishment it was highly impressive. Except, well frankly I was just a bit bored and felt like I was going through the motions.
Some parts were just a bit too long, some were too short, some parts were frustratingly difficult (particularly the helicopter battles) and I just didn't enjoy it all that much.
So it deserves some of your time, especially as it's free, but don't expect to love it :-(
Weeeell, it was OK. Certainly there was nothing wrong with it and as a technical accomplishment it was highly impressive. Except, well frankly I was just a bit bored and felt like I was going through the motions.
Some parts were just a bit too long, some were too short, some parts were frustratingly difficult (particularly the helicopter battles) and I just didn't enjoy it all that much.
So it deserves some of your time, especially as it's free, but don't expect to love it :-(
Tuesday, 18 December 2012
Darksiders II
So it's Zelda without the Nintendo charm, Bayonetta without the style, It's God of War. It's Shadow of the Colossus. I'm sure there was some Bionic Commando in there. Don't think this game has an original bone in its body!
On the positive, it's very well put together and really good fun (apart from the Gears of War bit) - so definitely worth playing.
Monday, 3 December 2012
Skyrim
Well... I guess I liked it. I mean, I played it for (at least) 120 hours so I must have liked it, right?
I didn't like the way it kind of forced you to take on all the evil missions as well as the good ones. Role-playing went out of the window quite quickly and it was just a game.
There were certainly some great moments, but there did seem like an awful lot of random-quest type filler. I mean hours and hours of it. I suppose completely open-world games just don't suit me - I like a bit more focus and direction, a more carefully paced story and, frankly, something a bit shorter!
Now I come to think of it, the actual combat was pretty weak too...
Obviously this is far too late to be a useful review for anyone - if you're going to play it, you already have. But then, I'm just writing these posts for me, not anyone else - I'd have to write much better articles if that was the intent :-D
So yeah. I liked it. Good game. Glad I played it. Glad it's finished!
I didn't like the way it kind of forced you to take on all the evil missions as well as the good ones. Role-playing went out of the window quite quickly and it was just a game.
There were certainly some great moments, but there did seem like an awful lot of random-quest type filler. I mean hours and hours of it. I suppose completely open-world games just don't suit me - I like a bit more focus and direction, a more carefully paced story and, frankly, something a bit shorter!
Now I come to think of it, the actual combat was pretty weak too...
Obviously this is far too late to be a useful review for anyone - if you're going to play it, you already have. But then, I'm just writing these posts for me, not anyone else - I'd have to write much better articles if that was the intent :-D
So yeah. I liked it. Good game. Glad I played it. Glad it's finished!
Thursday, 3 February 2011
YAGNI. Or are you...?
"You Ain't Gonna Need It" - for me, one of the most completely misused pieces of jargon in the Agile lexicon.
More than anything else, this has been responsible for the misapprehension that agile processes are nothing more than hack-n-fix. The fact is, in many places it's not a misapprehension!
Don't fancy writing any technical documentation for the development you're doing?
"You Ain't Gonna Need It" - it's not like anyone ever reads spec's anyway
Don't feel like writing any user documentation?
"You Ain't Gonna Need It" - the functionality will probably change loads before you release it
Code comments?
"You Ain't Gonna Need It" - not with your brilliantly clear declarative coding style
Architectural design for complex system?
"You Ain't Gonna Need It" - make it do what it needs to do for the story you're on. We can't possibly know what we'll need in the future, so we'll just refactor it when we need to next year / sprint / week / tomorrow...?
Wellllll - yeah. But that's rubbish, isn't it? Sometimes you DO know what you're going to need.
What about the guy who's got to support the product or teach people how to use it?
What about the guy who's got to fix the bug or add the new feature in a year's time, who can't follow your brilliant style (and who will probably be you!)
What about the time you'll waste retro-fitting the architecture you could have got right in the first place?
Like any rule applied blindly and without thinking, YAGNI can get you into all sorts of trouble. Maybe more so.
Of course you shouldn't waste time writing complex technical documentation that no-one's ever going to read (although you should probably find out what it is they DO want, before doing nothing)
Of course you shouldn't comment your code like a first year under-grad and proudly tell everyone you're incrementing counter "i" by 1
And of course you shouldn't develop a powerful, flexible, reusable library for something you don't have any particular plans to do again
But you should at least think about what you do know.
Unless you don't need to do that either...
More than anything else, this has been responsible for the misapprehension that agile processes are nothing more than hack-n-fix. The fact is, in many places it's not a misapprehension!
Don't fancy writing any technical documentation for the development you're doing?
"You Ain't Gonna Need It" - it's not like anyone ever reads spec's anyway
Don't feel like writing any user documentation?
"You Ain't Gonna Need It" - the functionality will probably change loads before you release it
Code comments?
"You Ain't Gonna Need It" - not with your brilliantly clear declarative coding style
Architectural design for complex system?
"You Ain't Gonna Need It" - make it do what it needs to do for the story you're on. We can't possibly know what we'll need in the future, so we'll just refactor it when we need to next year / sprint / week / tomorrow...?
Wellllll - yeah. But that's rubbish, isn't it? Sometimes you DO know what you're going to need.
What about the guy who's got to support the product or teach people how to use it?
What about the guy who's got to fix the bug or add the new feature in a year's time, who can't follow your brilliant style (and who will probably be you!)
What about the time you'll waste retro-fitting the architecture you could have got right in the first place?
Like any rule applied blindly and without thinking, YAGNI can get you into all sorts of trouble. Maybe more so.
Of course you shouldn't waste time writing complex technical documentation that no-one's ever going to read (although you should probably find out what it is they DO want, before doing nothing)
Of course you shouldn't comment your code like a first year under-grad and proudly tell everyone you're incrementing counter "i" by 1
And of course you shouldn't develop a powerful, flexible, reusable library for something you don't have any particular plans to do again
But you should at least think about what you do know.
Unless you don't need to do that either...
Tuesday, 1 February 2011
What's in a Name?
In response to some comments in another interesting post on Stuart Lynn's blog I asked if we could stop using "Waterfall" as a generic term for "non-Agile" processes.
Guy Letts then asked me the rather obvious question via Twitter:
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Guy Letts then asked me the rather obvious question via Twitter:
Your suggestions for a better term...?The short answer, that I gave Guy, was "Traditional".
Here's the long-winded version!
Waterfall was originally (at least according to wikipedia <ahem> <poor research>) described by Dr. Winston W. Royce as an example of a deliberately flawed and broken system.
In my own university days, it was used as a teaching method to identify the stages of the software project life-cycle, but even then it was made clear that this wasn't a practical approach to use in the real world.
The problem with using the term "Waterfall" like this is that the flaws of the method are obvious. This invites the straw-man attack from those pushing an Agile agenda - "Waterfall is bad, therefore all similar approaches are also bad".
This is just as divisive and unproductive as the "it's all code-and-hack-and-fix" claims of the Agile-skeptics.
As it happens, and as I'll discuss in a future post, I think that the differences between the two approaches aren't as great as some people would have us believe. I think that applying generalised labels can create mind-sets which inform thinking and lead people to believe they have to take "sides". This is potentially harmful and benefits no-one but the guys with books to sell!
We should be able to look at all the tools available to use and choose the appropriate set for the job we have to do and the people who will be doing it.
That said, I started this, so...
A term that's commonly used in Agile circles is "Big Design Up-Front".
That's nice and descriptive, but has several drawbacks:
- It's a bit of a mouthful
- It tends to be used in scathing tones that imply all up-front design is wasteful. Which is ludicrous
- It abbreviates to "BDUF", which sounds vaguely insulting
Again, there's an implicit assumption that Agile approaches are inherently better and that it's "wrong" to use anything else. That might be great if your audience is already in the club, but it's not an approach likely to win hearts and minds!
So why do I like the term "Traditional"?
What I really like is that it balances the positive and negative implications nicely:
- It recognises that there may be newer alternatives that may have advantages
- It doesn't imply an assumption that newer is always better. These methods have been used successfully for many years; they have been refined over time and many people are attached to them.
Introducing new approaches, we need to be certain that we understand the value of existing practices and ensure we're not losing anything.
We need to be aware that logical arguments aren't effective for addressing opinions based on long experience or emotion.
And we need to understand that insulting people doesn't help!
Agile Consultants
Time for a bit of disclosure - before it becomes too obvious from my other posts:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
I've had some poor experiences of "Agile Consultants"
Don't get me wrong, there are some good people out there - guys who can come in and genuinely have a positive impact on your business.
The problem is the other kind - the kind who:
- is a hacker who's never delivered a large-scale solution
- who sees process discussions as an argument to be won
- who can convince senior management to part with a pile of cash then blame the failure on the development team who "just don't get it"
- who was in the right place at the right time, and wrote his/her meal-ticket because of who they were standing next to
Yes, I'm being overly cynical - but there are a lot of consultants on the band-wagon and there are people like this out there. If you are looking to bring someone in, do your research properly:
- Talk to their previous clients
- Find out what their ROI was 6 months later... 2 years later
- Talk to the developers and find out what they thought
- And be wary of promises that sound too good to be true...
And if you think I've been too cynical, then read this anonymous, satirical, blog written by someone (not me) with similar experiences and a better sense of comic timing!
Subscribe to:
Posts (Atom)