A few years ago I tried World of Warcraft. It was alright, but my network connection had sufficient lag to make game play occasionally awkward.
I've recently got a World of Warcraft Battle Chest double-DVD box with the original game plus Burning Crusade and, since my network download speed is now over 30 meg actual (thanks BT), latency is no longer an issue.
Whilst editing the gamebook FNH and I are doing I figured I'd set it installing in the background.
After 2 DVDs and 100mb of updates the game folder is at 11.9gb. I expected some extra patching to be needed (it always has in the past) but even though I can now play the game it breezily tells me it is downloading another 9gb.
If I was downloading the client from scratch that's maybe okay, even if I'd had to download the previous 11gb, but to issue a boxed set with 2 complete DVDs and still expect another 9gb download - my response is simply what the f**k was the point of bothering with the bloody DVDs?
I don't swear. So much so in fact that others notice and comment upon it. So it has meaning when I say that Blizzard have p***ed me off so much that I cancelled the download and the box will head off to a charity shop somewhere. Or more likely the bin.
Sunday, 22 January 2012
Thursday, 19 January 2012
Following a Windows Phone 7 Game-Creating Tutorial
Having a day off work I spent this afternoon with Visual Studio 2010 and the Windows Phone 7 SDK going through a tutorial on creating a Space Invaders clone (Mars Invaders). Okay, it's not actually a clone (more similar to Galaga, Phoenix and the like), but Space Invaders is very well known and similar enough to get the gist.
Tutorial
http://msdn.microsoft.com/en-us/library/hh413206(v=vs.88).aspx
In the absence of a real phone I was expecting the performance of a game in the emulator to be an issue but was pleasantly surprised. I created a new XNA game project and went through the tutorial step by step creating the game so I understood every line as much as possible and, with one exception, it worked perfectly. A refreshing change from the 80's days of entering listings from magazines and them rarely working!
For reference, if you are planning on doing the tutorial yourself here's the exception. There is code in there to switch between accelerometer control and keyboard depending upon whether running on the emulator or a device, but in my own case I had to disable the checks and always use the accelerometer (which works in the emulator via the 3D phone drag). There may be a second exception, but I put it down to me missing something: at one point the tutorial said to make a change after an 'if' statement in the PlayerShip.Update routine but in the code I had created up to that point (and in fact beyond) there was no such 'if' statement, implying missing code. I copied the method contents from the tutorial source (it was longer) and it all worked.
The performance was more than acceptable, though obviously real devices will vary.
Coding games in C# is nice. I have my own C# game engines I've done in the past using GDI+ (there were reasons, honest) so this way of working was very familiar. I was especially pleased with the event-driven model of the game (Update and Draw events make things easy), and equally so with the way you can create a DrawableGameComponent-derived class and by simply adding it to the game's Components any instance of it is automatically enrolled and it's own equivalent events called. Simple concept, but neatly done.
My main concern going into this was screen displays. Although currently Windows Phone 7 only has two screen resolutions in the wild, coping with both those plus future ones could be a headache. Turns out it isn't though.
One of the requirements of the devices (in order to be certified) is a hardware scaler, which works independently of the GPU and apparently has effectively zero performance impact. What it means in practice is that you pick a resolution (480x800 ideally) and code everything assuming that. The scaler automatically and at high quality scales the display output to the phone resolution and also scales the touch input so you can, quite literally, ignore the entire issue.
Incidentally, the scaler guarantees no change to the aspect ratio so if necessary black areas will be there, like letterbox widescreen.
So with minimal code the tutorial end result is an event-driven, object based Space Invaders clone with background image, starting screen, fleets of ships, missiles, scoring, multiple lives, background music (of a sort) and sound effects. Playable as a demo game, though by design not production standard, it was remarkably simple code - I'll definitely be looking at doing some of my own stuff for these phones.
Tutorial
http://msdn.microsoft.com/en-us/library/hh413206(v=vs.88).aspx
 |
| Mars Invaders |
For reference, if you are planning on doing the tutorial yourself here's the exception. There is code in there to switch between accelerometer control and keyboard depending upon whether running on the emulator or a device, but in my own case I had to disable the checks and always use the accelerometer (which works in the emulator via the 3D phone drag). There may be a second exception, but I put it down to me missing something: at one point the tutorial said to make a change after an 'if' statement in the PlayerShip.Update routine but in the code I had created up to that point (and in fact beyond) there was no such 'if' statement, implying missing code. I copied the method contents from the tutorial source (it was longer) and it all worked.
The performance was more than acceptable, though obviously real devices will vary.
Coding games in C# is nice. I have my own C# game engines I've done in the past using GDI+ (there were reasons, honest) so this way of working was very familiar. I was especially pleased with the event-driven model of the game (Update and Draw events make things easy), and equally so with the way you can create a DrawableGameComponent-derived class and by simply adding it to the game's Components any instance of it is automatically enrolled and it's own equivalent events called. Simple concept, but neatly done.
 |
| Emulator |
One of the requirements of the devices (in order to be certified) is a hardware scaler, which works independently of the GPU and apparently has effectively zero performance impact. What it means in practice is that you pick a resolution (480x800 ideally) and code everything assuming that. The scaler automatically and at high quality scales the display output to the phone resolution and also scales the touch input so you can, quite literally, ignore the entire issue.
Incidentally, the scaler guarantees no change to the aspect ratio so if necessary black areas will be there, like letterbox widescreen.
So with minimal code the tutorial end result is an event-driven, object based Space Invaders clone with background image, starting screen, fleets of ships, missiles, scoring, multiple lives, background music (of a sort) and sound effects. Playable as a demo game, though by design not production standard, it was remarkably simple code - I'll definitely be looking at doing some of my own stuff for these phones.
Wednesday, 18 January 2012
Windows 7 Mobile Development and Nokia Developer
I currently have a Blackberry.
Being very unimpressed with the quantity of apps available (the quality is generally very good) and having done some development for Windows Mobile 6 I thought I'd have a look at the tools available for newer Windows Phone development.
I like the look of the Nokia Lumia (though am stuck with the Blackberry for another year on contract) so as a C# developer by trade I downloaded the free Windows Phone SDK and Visual Studio.
I have to say, having used device emulators in the past, I like the completeness of the emulated phone and the tool-chain. I've signed up as a Nokia Developer, registered the SDK with Microsoft and will be looking into the possibilities with interest.
Now if only I had a real phone to test it on!
Being very unimpressed with the quantity of apps available (the quality is generally very good) and having done some development for Windows Mobile 6 I thought I'd have a look at the tools available for newer Windows Phone development.
I like the look of the Nokia Lumia (though am stuck with the Blackberry for another year on contract) so as a C# developer by trade I downloaded the free Windows Phone SDK and Visual Studio.
I have to say, having used device emulators in the past, I like the completeness of the emulated phone and the tool-chain. I've signed up as a Nokia Developer, registered the SDK with Microsoft and will be looking into the possibilities with interest.
Now if only I had a real phone to test it on!
Sunday, 15 January 2012
Charts of Endless Quest vs Fighting Fantasy
After writing my last post about using automation for gamebook testing I decided to try it on the Endless Quest books as I rather like them. They were written for a slightly younger audience than the Fighting Fantasy ones and have a different complexity level, being more like books with choices than games with some text.
Being quite thin paperbacks and given that many entries covered several pages, whereas the Fighting Fantasy often had the opposite of many entries per page, I was expecting far less branching choices but was still somewhat surprised at the result as I also ran the Fighting Fantasy Citadel of Chaos book through for comparison.
In the images below the game starts at the top and proceeds through to the green square to win, the red squares to lose, and the occasional grey dead-end for an almost-win (Endless Quest often allowed the player to partially complete the quest).
The result is obvious visually and makes clear the difference between FF with many, many branches of small text entries and EQ with its far less varied but much more wordy multi-page entries. Personally I prefer the EQ style despite the lower target age of the writing, but take a look ...
Being quite thin paperbacks and given that many entries covered several pages, whereas the Fighting Fantasy often had the opposite of many entries per page, I was expecting far less branching choices but was still somewhat surprised at the result as I also ran the Fighting Fantasy Citadel of Chaos book through for comparison.
In the images below the game starts at the top and proceeds through to the green square to win, the red squares to lose, and the occasional grey dead-end for an almost-win (Endless Quest often allowed the player to partially complete the quest).
The result is obvious visually and makes clear the difference between FF with many, many branches of small text entries and EQ with its far less varied but much more wordy multi-page entries. Personally I prefer the EQ style despite the lower target age of the writing, but take a look ...
|
|
Monday, 9 January 2012
Adventure Gambook Play-Testing
You may have noticed the progress bar at the top right which mentions a gamebook (if it's not there, the book is done so go ahead and buy it).
As of now my co-author (FNH) and I have both done all the entries, traps, encounters, puzzles and so forth and are doing proof-reading for quality and consistency of text across entries. After which comes play-testing.
Those of you who are writing, or considering writing, a gamebook may be intrigued to know that actual play-testing is being kept to a minimum.
Why and how?
The "why" is easy. Testing takes time and playing through a gamebook trying all combinations enough times to be happy with the outcome take a long time indeed. Anything that can reduce that is welcome.
Hence the "how".
The intention is to release in multiple formats, both electronic and paper. To do this, the traditional way of writing is not ideal as the final master manuscript would then need converting and massaging to suit each other format. If things change before publication then it needs doing again.
To get around this, we keep a master file (shared editing via Google Docs) which consists of entry titles, content, links, challenges and stats changes. This is in a standard format from which, using a C# tool I've developed, we can create a number of other formats (including RTF, HTML and EPUB) automatically and consistently, in seconds, on demand.
Given that this all exists to support the writing it took only a few more steps to add in automated play-testing. The tool will now run through the gamebook a chosen number of times, with average player stats, making choices, performing challenges, engaging in combat, collecting and using items, receiving damage and so forth. Choices are random, but bad ones are remembered for the player being simulated and are then avoided on the next run through. When/if the computer player completes the game a new computer player starts learning from scratch.
The end result?
A large number of test runs on demand. Only minor intelligence is displayed, with a minimal amount of learning, but it is good for a representative overview.
From that run we get details of how many attempts a minimally intelligent computer player takes to finish the book, how often each entry is visited, where players usually die (whether outright or through cumulative damage), which entries are most travelled by players who complete the game, and more. We get completely laid out graphs of these so we can see it all at a glance. We also get an automatically generated bestiary with creature stats.
Half a million runs through the book in around 4 minutes, summarised into entry map images.
We still need manual play-testing to confirm/clarify, especially as a human plays differently to a computer, but we know in advance which entries cannot be reached, which loop back inconsistently, which branches are most frequently visited (which is where most images should go) and more.
I'm saying all this to make a point.
Play-testing is onerous and time-consuming. Multiple format presentation is too. If you can code, or know a coder, make it easy on yourself and create a tool with a standard input. Or search for one that's already out there. Even if it only does basic consistency checks and no more that's a great deal of testing done away with.
Automate. You get ease and consistency as a result.
As of now my co-author (FNH) and I have both done all the entries, traps, encounters, puzzles and so forth and are doing proof-reading for quality and consistency of text across entries. After which comes play-testing.
Those of you who are writing, or considering writing, a gamebook may be intrigued to know that actual play-testing is being kept to a minimum.
Why and how?
The "why" is easy. Testing takes time and playing through a gamebook trying all combinations enough times to be happy with the outcome take a long time indeed. Anything that can reduce that is welcome.
Hence the "how".
The intention is to release in multiple formats, both electronic and paper. To do this, the traditional way of writing is not ideal as the final master manuscript would then need converting and massaging to suit each other format. If things change before publication then it needs doing again.
To get around this, we keep a master file (shared editing via Google Docs) which consists of entry titles, content, links, challenges and stats changes. This is in a standard format from which, using a C# tool I've developed, we can create a number of other formats (including RTF, HTML and EPUB) automatically and consistently, in seconds, on demand.
Given that this all exists to support the writing it took only a few more steps to add in automated play-testing. The tool will now run through the gamebook a chosen number of times, with average player stats, making choices, performing challenges, engaging in combat, collecting and using items, receiving damage and so forth. Choices are random, but bad ones are remembered for the player being simulated and are then avoided on the next run through. When/if the computer player completes the game a new computer player starts learning from scratch.
The end result?
A large number of test runs on demand. Only minor intelligence is displayed, with a minimal amount of learning, but it is good for a representative overview.
From that run we get details of how many attempts a minimally intelligent computer player takes to finish the book, how often each entry is visited, where players usually die (whether outright or through cumulative damage), which entries are most travelled by players who complete the game, and more. We get completely laid out graphs of these so we can see it all at a glance. We also get an automatically generated bestiary with creature stats.
Half a million runs through the book in around 4 minutes, summarised into entry map images.
We still need manual play-testing to confirm/clarify, especially as a human plays differently to a computer, but we know in advance which entries cannot be reached, which loop back inconsistently, which branches are most frequently visited (which is where most images should go) and more.
I'm saying all this to make a point.
Play-testing is onerous and time-consuming. Multiple format presentation is too. If you can code, or know a coder, make it easy on yourself and create a tool with a standard input. Or search for one that's already out there. Even if it only does basic consistency checks and no more that's a great deal of testing done away with.
Automate. You get ease and consistency as a result.
Subscribe to:
Posts (Atom)