June 30, 2005
Back...
Need to go shopping and decompress. Post a summary later. Nice meeting Andy from The Z-Buffer, however.
June 26, 2005
Dark For Real...
I know I've been quite chatty on what is supposed to be a "dark" blog, but I'm definitely going to be quiet until at least Thursday.
I leave tomorrow afternoon for Seattle, so if anyone here is going to GameFest, look out for me. I'll be the buzz-cut schmuck in a Ritual T-shirt.
I leave tomorrow afternoon for Seattle, so if anyone here is going to GameFest, look out for me. I'll be the buzz-cut schmuck in a Ritual T-shirt.
June 23, 2005
Off-Topic: Texas Hold'em Hand of WTF
We have a group here at Ritual that plays Texas Hold'em poker at lunch each day for fun. It's a great way to relieve tension, bond with your fellow co-workers, and just have some fun. It's also a way to encounter some of the strangest poker hands of all time.
An example:
Before the flop, one of my opponents went all-in. Everyone else folded but me. I called.
At this point, because it's "heads-up" (only two players, all-in), we put our cards face up. He has pocket aces. I have a king and an eight. He's winning.
The flop (first 3 cards) comes out. King, Ten, King. I'm now winning (3 Kings vs. Pair of Aces/Pair of Kings).
The turn (4th card) comes out. Ace. He's winning now (Full house [Aces full of Kings] vs. 3 Kings).
The river (5th and final card) comes out. The dealer looks at the card before placing it on the table and says, "You will not fuckin' believe this!" The last king. I won with a four-of-a-kind.
Why couldn't I have gotten hands like that last night during the poker tournament?
An example:
Before the flop, one of my opponents went all-in. Everyone else folded but me. I called.
At this point, because it's "heads-up" (only two players, all-in), we put our cards face up. He has pocket aces. I have a king and an eight. He's winning.
The flop (first 3 cards) comes out. King, Ten, King. I'm now winning (3 Kings vs. Pair of Aces/Pair of Kings).
The turn (4th card) comes out. Ace. He's winning now (Full house [Aces full of Kings] vs. 3 Kings).
The river (5th and final card) comes out. The dealer looks at the card before placing it on the table and says, "You will not fuckin' believe this!" The last king. I won with a four-of-a-kind.
Why couldn't I have gotten hands like that last night during the poker tournament?
What Managed DirectX Needs To Succeed
First off, I like Managed DirectX. I think it's an efficient, coder-friendly multimedia development tool. However, I believe that it needs a few things in order to even make a dent in the market share for OpenGL or even non-managed DirectX.
1) Documentation. I don't care if it's C# only, but the documentation needs to be brought up to C++ standards. I shouldn't have to know all about normal DirectX 9 to use Managed DirectX. When I have to keep jumping back and forth between the Managed and Unmanaged documentation to find the info I need, the docs have failed.
It also doesn't help when every other topic in the documentation reads like a discontinued product. If you take a look at the DirectX SDK/Namespaces topic, 4 of the 13 topics have the following warning:
2) A showcase. You need a Managed DirectX product that you can point to and make people say, "Wow!" Unfortunately, the "Tin Soldiers" series isn't going to cut it. You need a real showcase.
You may remember that Vertigo Software ported Quake II to the .NET Framework to show what could be done with just managed code. Why not take it a step farther, convert that codebase to C# and Managed DirectX, and release it? Give MDX a fast-moving action showcase.
3) Cutting edge. When I look through the DirectX Sample Browser for June 2005, I see tons of samples that don't have managed counterparts. People look to the samples to see what can be done, and if they don't see a managed sample for it, they'll assume that MDX doesn't support it.
Right now, the following are C++ only:
1) Documentation. I don't care if it's C# only, but the documentation needs to be brought up to C++ standards. I shouldn't have to know all about normal DirectX 9 to use Managed DirectX. When I have to keep jumping back and forth between the Managed and Unmanaged documentation to find the info I need, the docs have failed.
It also doesn't help when every other topic in the documentation reads like a discontinued product. If you take a look at the DirectX SDK/Namespaces topic, 4 of the 13 topics have the following warning:
Warning: Microsoft DirectDraw (or other item) has been deprecated. Deprecated components of DirectX 9.0 for Managed Code are considered obsolete. While these components are still supported in this release of DirectX 9.0 for Managed Code, they may be removed in the future. When writing new applications, you should avoid using these deprecated components. When modifying existing applications, you are strongly encouraged to remove any dependency on these components.You don't get that with the C++ documentation. If you don't want us using it, drop the docs.
2) A showcase. You need a Managed DirectX product that you can point to and make people say, "Wow!" Unfortunately, the "Tin Soldiers" series isn't going to cut it. You need a real showcase.
You may remember that Vertigo Software ported Quake II to the .NET Framework to show what could be done with just managed code. Why not take it a step farther, convert that codebase to C# and Managed DirectX, and release it? Give MDX a fast-moving action showcase.
3) Cutting edge. When I look through the DirectX Sample Browser for June 2005, I see tons of samples that don't have managed counterparts. People look to the samples to see what can be done, and if they don't see a managed sample for it, they'll assume that MDX doesn't support it.
Right now, the following are C++ only:
- DirectSound Amplitude Modulation
- Antialiasing
- Blobs
- Application Configuration Systems
- Custom Data Formats
- Direct3D Depth Of Field
- DirectX Diagnostic Report
- DirectX Install
- Effect Parameters
- Firewall API's
- DirectSound Full Duplex Filter
- GetDXVer
- HDR Lighting
- Install-on-Demand
- Instancing
- Local Deformable PRT
- Creating a Mesh from a Wavefront .OBJ
- Multi-Animation
- Optimized Mesh
- PIX Plugins (understandable, though)
- Pixel Motion Blur
- Post-Processing
- RTHDRIBL
- Shadow Maps
- Shadow Volumes
- State Managers
- Voice Management
- HLSL Workshop
It adds up. Give us parity, or forget it.
Anyway, back to work.
June 22, 2005
How To Tell When You Are Obsessed About Work...
I was at a Texas Hold'em tournament until 11:20pm. I came home, and I've spent the last 40 minutes getting caught up on postings about some "viral" thing or other, as well as working on a testing tool for an entirely different product.
Joyous rapture and harmony. At least I was able to give some the Z-Buffer some Managed DirectX Google Juice.
It's Thursday morning now, so I'm off to bed.
Joyous rapture and harmony. At least I was able to give some the Z-Buffer some Managed DirectX Google Juice.
It's Thursday morning now, so I'm off to bed.
Off-Topic: One of these things...
One of these things is not like the other, I wonder if you can tell me which one...
Blech...
Sorry the blog has been more silent than expected these last few days. Milestone last week, milestone this week, GameFest next week, plus there's this whole "viral" thing going around...it takes a toll on free time.
Anyway, just letting you know that I'll probably be mostly silent until the first week in July. Then, I've got a whole slew of updates I can bring to the blog. I just don't have the time (or in some cases, permission) to do so until then.
Anyway, just letting you know that I'll probably be mostly silent until the first week in July. Then, I've got a whole slew of updates I can bring to the blog. I just don't have the time (or in some cases, permission) to do so until then.
June 17, 2005
June 16, 2005
So I'm going to be published...
Evidently, a small article of mine is going to be published in an upcoming issue of (game)land Magazine in Russia, which talks about efforts that are being made to make the PC gaming experience more console-like, i.e. it just works.
When I get a link, I'll post it.
When I get a link, I'll post it.
June 15, 2005
Question of the Week
Every week, I do an open question over at Ritual's fan site, Ritualistic.com. This is a non-Scoble-approved means of creating community discussion, but it's still effective.
The most recent question involved what our community thought about recent trends in gaming that they believed were bad and/or wrong. I gave a few examples to try to stir the pot.
I wasn't expecting the front-page response I got...but you can't really control the community. All you can do is harness their passion and hang on for the ride!
The most recent question involved what our community thought about recent trends in gaming that they believed were bad and/or wrong. I gave a few examples to try to stir the pot.
I wasn't expecting the front-page response I got...but you can't really control the community. All you can do is harness their passion and hang on for the ride!
June 13, 2005
Test Plan #2: Milestone Acceptance Criteria
Okay, so it's been 11 days since my last installment...I've been busy.
After my smoke tests, I usually include common criteria that will be appended to each milestone acceptance test. Since these usually include overarching goals, it's best to make sure that they're established and signed off on up front.
In addition, "Acceptance Criteria" may be a bit of a misnomer. You specifically want to list anything that will cause you to fail a milestone, because that's what the team will care about most.
For example, this is a section from my "Milestone Acceptance" section on [deleted]:
Numbers 1 and 2 are there simply to act as a deterrent against submitting unstable builds. If a build can't last an hour without crashing, why am I looking at it as a progress milestone? The three-crash bar acts as an additional stabilizer.
Numbers 3 and 4 are pretty basic as well. Milestones are supposed to have a certain set of deliverables. Those deliverables may be shuffled between milestones, but what is delivered in a milestone is expected to 1)be there; and 2)work. While there may occasionally be dickering regarding what is a major or minor feature, that's a small price to pay for making sure that each milestone has what it says it will have.
Numbers 5 through 10 are very specific to the title. In [deleted], the goal is to have the entire game capable of being played through very early, so as part of my acceptance test, I'd go through and play the entire game from beginning to end.
Finally, we have number 11. This one is the one that people usually get the most grief over. Every project has a bug database. It may be just E-mail going back and forth, it may be an Excel spreadsheet, it may be a modified version of IssueTracker, it may be a full-featured bug client like Seapine TestTrack Pro, but you always track your bugs. The goal of this is to make sure that major bugs don't carry over from milestone to milestone.
Bugs are always rated by the test team on their severity. Severity levels are fairly well defined, and severity 1 is the worst. For a bug to be severity 1, it must be either a crash bug, cause data loss, cause the title to fail certification on a console platform, or be a bug that would definitely cause the product not to ship.
Every product has these sev 1 bugs. The more you have active, the less stable your product really is. The goal is to keep no more than ten of them on our plate from milestone to milestone.
The biggest issue you are going to see if you implement a severity bar in your MAT is a mass-resolve of bugs just prior to a milestone. Easiest solution: tell them that reactivations of sev-1 bugs count towards the 10. It may seem cheap, but so is trying to get around the submission guidelines.
Milestones are there for one reason and one reason only: to act as a constant heartbeat for a project. Publishers pay when they feel the pulse. If your product doesn't have a decent pulse, then it's crisis time.
After my smoke tests, I usually include common criteria that will be appended to each milestone acceptance test. Since these usually include overarching goals, it's best to make sure that they're established and signed off on up front.
In addition, "Acceptance Criteria" may be a bit of a misnomer. You specifically want to list anything that will cause you to fail a milestone, because that's what the team will care about most.
For example, this is a section from my "Milestone Acceptance" section on [deleted]:
A milestone shall be considered to have failed if any of the following are true:The above may seem very harsh, but it's also very common in video gaming...especially from a publisher standpoint. More and more, publishers are including stability bars in their milestone acceptance criteria. So let's walk through the list really quickly.
1. A reproducible crash is found during the first sixty (60) minutes of testing the milestone.
2. Three (3) reproducible crashes are found during the first eight (8) hours of testing the milestone.
3. One (1) major milestone deliverable is found to be not implemented or non-functional during the testing of the milestone.
4. Three (3) minor milestone deliverables are found to be not implemented or non-functional during the testing of the milestone.
5. At least one (1) level transition does not work.
6. At least one (1) level cannot be completed without using the “noclip” cheat.
7. At least one (1) level does not load.
8. At least one (1) weapon does not work.
9. At least one (1) multiplayer mode does not work.
10. A multiplayer game cannot be hosted or joined.
11. If there are more than ten (10) active severity 1 bugs in the [deleted] bug database.
A milestone shall not be considered passed until the milestone has passed a milestone acceptance test.
Numbers 1 and 2 are there simply to act as a deterrent against submitting unstable builds. If a build can't last an hour without crashing, why am I looking at it as a progress milestone? The three-crash bar acts as an additional stabilizer.
Numbers 3 and 4 are pretty basic as well. Milestones are supposed to have a certain set of deliverables. Those deliverables may be shuffled between milestones, but what is delivered in a milestone is expected to 1)be there; and 2)work. While there may occasionally be dickering regarding what is a major or minor feature, that's a small price to pay for making sure that each milestone has what it says it will have.
Numbers 5 through 10 are very specific to the title. In [deleted], the goal is to have the entire game capable of being played through very early, so as part of my acceptance test, I'd go through and play the entire game from beginning to end.
Finally, we have number 11. This one is the one that people usually get the most grief over. Every project has a bug database. It may be just E-mail going back and forth, it may be an Excel spreadsheet, it may be a modified version of IssueTracker, it may be a full-featured bug client like Seapine TestTrack Pro, but you always track your bugs. The goal of this is to make sure that major bugs don't carry over from milestone to milestone.
Bugs are always rated by the test team on their severity. Severity levels are fairly well defined, and severity 1 is the worst. For a bug to be severity 1, it must be either a crash bug, cause data loss, cause the title to fail certification on a console platform, or be a bug that would definitely cause the product not to ship.
Every product has these sev 1 bugs. The more you have active, the less stable your product really is. The goal is to keep no more than ten of them on our plate from milestone to milestone.
The biggest issue you are going to see if you implement a severity bar in your MAT is a mass-resolve of bugs just prior to a milestone. Easiest solution: tell them that reactivations of sev-1 bugs count towards the 10. It may seem cheap, but so is trying to get around the submission guidelines.
Milestones are there for one reason and one reason only: to act as a constant heartbeat for a project. Publishers pay when they feel the pulse. If your product doesn't have a decent pulse, then it's crisis time.
Off-Topic: Bloggin' my Way To PDC (Entry)
(To the tune of Pinball Wizard by The Who)
Ever since I was a young boy
I wrote stuff in my blog;
Three hundred fifty posts,
If you want to read 'em all;
But at these dev conferences,
I'm never seen at all;
This game testin' whack job
Knows how to make code fall!
I sit like a statue
Become part of the machine
Checking all the inputs
Never playing clean
I test by intuition
Those bugs, I find 'em all
This game testin' whack job
Knows how to make code fall!
I'm a testin' wizard,
The bugs are in my fist!
For a testin' wizard,
Finding bugs is bliss!
(How do you think he does it?)
(Caffiene buzz?)
(Coke...it does him good...)
I test all the distractions;
I check those buzzers and bells,
I make sure lights are flashing,
I respect your sense of smell,
So what you get to play
Never fails at all.
This game testin' whack job
Knows how to make code fall!
You thought you were
The code-writing king,
But you just handed
A bug-filled mess to me...
Even on my favorite projects,
I still run my tests.
With this experience,
My tests will be the best.
So send me to the conference
And get behind the ball...
This game testin' whack job
Knows how to make code fall!
WORKAROUND: The RPC server is unavailable.
Are you using Windows XP Media Center Edition 2005 and are trying to sync content to a portable device? Does all of the content in .WMV, .WMA and .MP3 format make it over, but nothing else does? Does the rest of your content show up in the Media Center application as "An error occurred copying this file" and in Media Player 10 as "The RPC server is unavailable"?
Fear not. The solution is simple, but it is a bit of a pain in the ass. It seems that for whatever reason, on some Media Center installs, files will not properly convert and/or copy over to your portable device if the Media Center application is currently receiving a Live TV signal.
To fix it, do the following:
1) Close the Media Center application. (Right-click in the TV window to bring up the top and bottom bars [works more reliably than moving the mouse], click the "X" up in the corner.)
2) Wait 30 seconds, then bring up Task Manager. (Right Click on time, select Task Manager; or hit Ctrl-Alt-Esc.)
3) Make sure none of the following tasks are running: wmplayer.exe, ehshell.exe, wm8enc.exe. If any of those three tasks are running, click on the task and select "End Process." If you are using Process Explorer, right click on the task and select "Kill Process Tree."
4) Connect your portable device. Launch Windows Media Player 10 if it doesn't automatically launch.
5) Go to the "Sync" tab. Make sure your device is shown.
6) Click "Start Sync." Files should actually be converting.
At this point, you can hit the Big Green Button™ and start the Media Center application again. As long as you don't start watching Live TV, you should be fine using the rest of the app. However, if you start watching Live TV, chances are that the wm8enc.exe task will hang again and you'll have to start again from step 1.
I hate having to come up with workarounds for things that are supposed to just work...
Fear not. The solution is simple, but it is a bit of a pain in the ass. It seems that for whatever reason, on some Media Center installs, files will not properly convert and/or copy over to your portable device if the Media Center application is currently receiving a Live TV signal.
To fix it, do the following:
1) Close the Media Center application. (Right-click in the TV window to bring up the top and bottom bars [works more reliably than moving the mouse], click the "X" up in the corner.)
2) Wait 30 seconds, then bring up Task Manager. (Right Click on time, select Task Manager; or hit Ctrl-Alt-Esc.)
3) Make sure none of the following tasks are running: wmplayer.exe, ehshell.exe, wm8enc.exe. If any of those three tasks are running, click on the task and select "End Process." If you are using Process Explorer, right click on the task and select "Kill Process Tree."
4) Connect your portable device. Launch Windows Media Player 10 if it doesn't automatically launch.
5) Go to the "Sync" tab. Make sure your device is shown.
6) Click "Start Sync." Files should actually be converting.
At this point, you can hit the Big Green Button™ and start the Media Center application again. As long as you don't start watching Live TV, you should be fine using the rest of the app. However, if you start watching Live TV, chances are that the wm8enc.exe task will hang again and you'll have to start again from step 1.
I hate having to come up with workarounds for things that are supposed to just work...
June 12, 2005
Mini-Review: ICO (PS2)
I finally got around to picking up "ICO" yesterday for $17.99 at EBGames. If you want to know more about it, check out GameSpy's review here.
Now for my feelings...this game is by far one of the most real games I've ever played. Every character animation from Yorda's idle animations to the strain on Ico when he's holding onto Yorda to keep her from faling to her death, all of them are done to perfection. The shadow demons are infinitely more menacing than any other monsters seen to date on the PS2, and that's saying a lot.
The story is inferred more than told, but that's good. This is one of the few games where your attachment to the characters comes via the gameplay and not via the cutscenes. If you aren't completely committed to getting Yorda out of the castle by the time you get to the windmill, then you are seriously in need of psychological counseling. By the way, turn on vibration when you start a new game. When you are holding Yorda's hand to guide her around, you can feel her pulse through the controller. Now that's immersion.
There are a few areas where you may need hints (which you can get here) but the platforming aspect isn't too hard. The puzzle aspect is where the game is at. While the game is rated T for Teen, it's okay for all ages as far as I'm concerned.
A few tips from me: The circle button is your friend. If you find your self constantly wandering off of ledges, press and hold your circle button to walk. You'll have more control. You can light your stick by tapping your circle button next to a fire source. Find a save point after each fight...you'll be glad you did. If Yorda is in one of the shadow demon voids, stand on her, hold your R1 button, and move away from the void to pull her out.
It took be about 7 hours to beat the game. While I would have been pissed off completely if I had paid $50 for it, it was well worth the sub-$20 price I paid for it, and I'm looking forward to this team's next title, "Shadow of the Colossus."
Now for my feelings...this game is by far one of the most real games I've ever played. Every character animation from Yorda's idle animations to the strain on Ico when he's holding onto Yorda to keep her from faling to her death, all of them are done to perfection. The shadow demons are infinitely more menacing than any other monsters seen to date on the PS2, and that's saying a lot.
The story is inferred more than told, but that's good. This is one of the few games where your attachment to the characters comes via the gameplay and not via the cutscenes. If you aren't completely committed to getting Yorda out of the castle by the time you get to the windmill, then you are seriously in need of psychological counseling. By the way, turn on vibration when you start a new game. When you are holding Yorda's hand to guide her around, you can feel her pulse through the controller. Now that's immersion.
There are a few areas where you may need hints (which you can get here) but the platforming aspect isn't too hard. The puzzle aspect is where the game is at. While the game is rated T for Teen, it's okay for all ages as far as I'm concerned.
A few tips from me: The circle button is your friend. If you find your self constantly wandering off of ledges, press and hold your circle button to walk. You'll have more control. You can light your stick by tapping your circle button next to a fire source. Find a save point after each fight...you'll be glad you did. If Yorda is in one of the shadow demon voids, stand on her, hold your R1 button, and move away from the void to pull her out.
It took be about 7 hours to beat the game. While I would have been pissed off completely if I had paid $50 for it, it was well worth the sub-$20 price I paid for it, and I'm looking forward to this team's next title, "Shadow of the Colossus."
June 10, 2005
"Don't @*&#$( with nerds."
http://neopoleon.com/blog/posts/14683.aspx
Great story, one swear word at the end...and I agree, I'd buy the T-shirt as well.
Great story, one swear word at the end...and I agree, I'd buy the T-shirt as well.
June 9, 2005
Farewell, good friend...
This morning, one of my most faithful companions finally bit the bullet after nearly six years of service.
Back when I was up at Microsoft's Redmond campus in October 1999, I bought a durable metal retractable lanyard for my badge from the company store for $3.50 plus tax. I kept that lanyard the entire time I was at Microsoft. While at Microsoft, I had to replace the badge clip twice, but the mechanism worked like a charm.
At Layton City, we used sensor badges to get in, and again, my lanyard worked well. Admittedly, it was getting pretty scuffed up. You could barely make out the extension for Microsoft Security that was printed on the face, and I had to replace the clip another two times, but it continued to serve me well.
This morning, I reached for my card on my belt clip and pulled it towards the badge reader and heard a sickening "click" from inside the retracting mechanism. As soon as I heard the click, all of the thread inside just fell out. I couldn't save it this time, even though I wanted to.
My lanyard died at 9:57am this morning. A private ceremony will be held this weekend. In lieu of flowers, say a prayer for the most reliable Microsoft product I have ever used.
Speaking of Microsoft, I received an E-mail today from Microsoft Recruiting asking if I wanted to interview for a position on the Longhorn team. I declined. After all, Longhorn may be the OS of the future, but I'm already working on the cutting edge. And trust me, once the gag comes off, you're going to hear all about it.
Back when I was up at Microsoft's Redmond campus in October 1999, I bought a durable metal retractable lanyard for my badge from the company store for $3.50 plus tax. I kept that lanyard the entire time I was at Microsoft. While at Microsoft, I had to replace the badge clip twice, but the mechanism worked like a charm.
At Layton City, we used sensor badges to get in, and again, my lanyard worked well. Admittedly, it was getting pretty scuffed up. You could barely make out the extension for Microsoft Security that was printed on the face, and I had to replace the clip another two times, but it continued to serve me well.
This morning, I reached for my card on my belt clip and pulled it towards the badge reader and heard a sickening "click" from inside the retracting mechanism. As soon as I heard the click, all of the thread inside just fell out. I couldn't save it this time, even though I wanted to.
My lanyard died at 9:57am this morning. A private ceremony will be held this weekend. In lieu of flowers, say a prayer for the most reliable Microsoft product I have ever used.
Speaking of Microsoft, I received an E-mail today from Microsoft Recruiting asking if I wanted to interview for a position on the Longhorn team. I declined. After all, Longhorn may be the OS of the future, but I'm already working on the cutting edge. And trust me, once the gag comes off, you're going to hear all about it.
Ads
Just as a heads-up, I added a small ad footer to each blog page in addition to the small ad in the top right corner.
Why? Simple math. Fourteen months of content + 17,000 visitors = $16 total in my Google AdSense account.
I don't want to flood this site with ads, so I'm not going to do any more than this. I just hope that by the time I hit 24 months of content, I'll at least get a check...
Why? Simple math. Fourteen months of content + 17,000 visitors = $16 total in my Google AdSense account.
I don't want to flood this site with ads, so I'm not going to do any more than this. I just hope that by the time I hit 24 months of content, I'll at least get a check...
June 8, 2005
June 7, 2005
Will Be Running A Little Dark Thanks To Test Cases
This blog is going to be running slightly darker for the next four weeks. I'm currently in the middle of my least favorite part of testing...writing test cases.
To give you an idea, on one of our unannounced products, I currently am only halfway done with the AI test cases, and I'm already up to 70k in just AI test case notes. These aren't even the full test cases, these are just my notes about what cases I have to write.
Test cases range in complexity. Some are very simple.
Some add extra steps.
Some are more difficult for some testers.
Some are so complex that a single test case can turn into several dozen.
I've got a lot of typing in front of me...
To give you an idea, on one of our unannounced products, I currently am only halfway done with the AI test cases, and I'm already up to 70k in just AI test case notes. These aren't even the full test cases, these are just my notes about what cases I have to write.
Test cases range in complexity. Some are very simple.
Verify model loads and renders.That's a simple test case. If it shows up, it passes the test.
Some add extra steps.
Using the @@@ cheat code, tell the engine to overlay hitboxes over the model.In this case, the tests depend on the use of a cheat code, so those tests get meshed together.
Verify that each hitbox fits the model.
Verify that each hitbox continues to fit the model during animation.
Some are more difficult for some testers.
Verify that if you shoot the model in the head, the enemy immediately dies.Okay, now we are requiring accuracy on the part of the tester to the point of shooting a specific target area.
Some are so complex that a single test case can turn into several dozen.
Verify that each line from this character plays in the appropriate language.That requires triggering each line of dialog in-game eight seperate times, each time with a seperate language. When the case is finished, this will probably turn into a grid with languages on the top and lines of dialog on the left.
Languages: English, French, Italian, German, Spanish, Japanese, Korean, Chinese
Lines: ...
I've got a lot of typing in front of me...
June 5, 2005
A-Kon 16
Yesterday, I went to A-Kon 16. It's the first time I ever went to an anime convention, and it was an interesting experience.
First off, all of the hygiene warnings that conventions have been spewing for the last several years finally paid off. I wasn't able to identify a single attendee by scent.
Second, video game characters seem to be getting more popular than anime characters. Over half of the cosplayers I saw were playing video game characters. I also saw several dozen black and red mages from "Final Fantasy I." However, when I spoke with a few of them, they weren't cosplaying those characters. They were cosplaying Brian Clevinger's versions from "8-bit Theater." There were dozens of extremely well done Link's from "The Legend of Zelda" running around...nearly all of which were female, including an adorable set of twins dressed as Blue and Red Link. Of course, the Homer Simpson "Mr. Sparkle" box and seeing the Prince from "Katamari Damacy" not once, but twice, really threw me for a loop.
Third, cosplayers seem to be getting the hint that you should cosplay characters that fit your body type. There were very few cosplayers that nightmares are made of. Of course, the skits were another thing entirely. Talk about "Revenge of High School Theater..."
GameSnark's cosplay gallery can be seen here. Once I get my photos back, I'll try scanning them in and sticking them somewhere.
So, if you are planning on attending a local anime convention near you for the first time, here are some survival rules.
1. Pre-register. It cost me $60 to get me and my wife in for one day. In comparison, if I pre-register for AnimeFest, it will cost me $60 to get me and my wife in for four days. Do the math.
2. Comfortable shoes with well-padded feet. I can't stress this enough. I wore my most comfortable shoes, but the soles didn't have enough padding, and my feet were killing me at the end of the day.
3. Ask before you shoot. While it's fairly obvious that you should bring a camera with plenty of film, it is considered polite to ask cosplayers for a photo prior to just snapping one. Plus, you'll usually get better shots that way.
4. A place to stick your stuff, and plenty of cash. Anime conventions have a lot of great stuff for sale, but not all of it can be easily carried. Either have a vehicle trunk you can stick stuff in or a room at the hotel to drop it off. In order to get some of the stuff my wife and I had picked up home, I had to leave the convention around 5, catch the train home, then come back. I didn't get back until almost 7. Also, while several places take Visa or MasterCard, a couple take American Express, and nobody takes Discover, everyone takes cash. I recommend that if you are planning on visiting the dealer area, plan on bringing your budget in cash. If you're planning on buying clothing or weapons, make it about $500, otherwise $200 should do fine. I was lucky. I managed to get out of there spending less than $100...but it wasn't easy.
5. Cosplayers, bring along a small sewing kit and tape. I saw plenty of small tears and, ahem, slips that shouldn't have happened but did. Bring the sewing kit so you can easily trim loose threads and patch any tears, and bring the tape so that your carefully balanced bustier won't flop down at an inappropriate time.
6. Have fun. There's no way you're going to get all of the freebies and see everything, even if you carefully schedule your entire stay...so don't even try. Pick out three things you have to see per day and make sure you see them, and spend the rest of the time just having fun. After all, isn't "fun" what these things are all about?
First off, all of the hygiene warnings that conventions have been spewing for the last several years finally paid off. I wasn't able to identify a single attendee by scent.
Second, video game characters seem to be getting more popular than anime characters. Over half of the cosplayers I saw were playing video game characters. I also saw several dozen black and red mages from "Final Fantasy I." However, when I spoke with a few of them, they weren't cosplaying those characters. They were cosplaying Brian Clevinger's versions from "8-bit Theater." There were dozens of extremely well done Link's from "The Legend of Zelda" running around...nearly all of which were female, including an adorable set of twins dressed as Blue and Red Link. Of course, the Homer Simpson "Mr. Sparkle" box and seeing the Prince from "Katamari Damacy" not once, but twice, really threw me for a loop.
Third, cosplayers seem to be getting the hint that you should cosplay characters that fit your body type. There were very few cosplayers that nightmares are made of. Of course, the skits were another thing entirely. Talk about "Revenge of High School Theater..."
GameSnark's cosplay gallery can be seen here. Once I get my photos back, I'll try scanning them in and sticking them somewhere.
So, if you are planning on attending a local anime convention near you for the first time, here are some survival rules.
1. Pre-register. It cost me $60 to get me and my wife in for one day. In comparison, if I pre-register for AnimeFest, it will cost me $60 to get me and my wife in for four days. Do the math.
2. Comfortable shoes with well-padded feet. I can't stress this enough. I wore my most comfortable shoes, but the soles didn't have enough padding, and my feet were killing me at the end of the day.
3. Ask before you shoot. While it's fairly obvious that you should bring a camera with plenty of film, it is considered polite to ask cosplayers for a photo prior to just snapping one. Plus, you'll usually get better shots that way.
4. A place to stick your stuff, and plenty of cash. Anime conventions have a lot of great stuff for sale, but not all of it can be easily carried. Either have a vehicle trunk you can stick stuff in or a room at the hotel to drop it off. In order to get some of the stuff my wife and I had picked up home, I had to leave the convention around 5, catch the train home, then come back. I didn't get back until almost 7. Also, while several places take Visa or MasterCard, a couple take American Express, and nobody takes Discover, everyone takes cash. I recommend that if you are planning on visiting the dealer area, plan on bringing your budget in cash. If you're planning on buying clothing or weapons, make it about $500, otherwise $200 should do fine. I was lucky. I managed to get out of there spending less than $100...but it wasn't easy.
5. Cosplayers, bring along a small sewing kit and tape. I saw plenty of small tears and, ahem, slips that shouldn't have happened but did. Bring the sewing kit so you can easily trim loose threads and patch any tears, and bring the tape so that your carefully balanced bustier won't flop down at an inappropriate time.
6. Have fun. There's no way you're going to get all of the freebies and see everything, even if you carefully schedule your entire stay...so don't even try. Pick out three things you have to see per day and make sure you see them, and spend the rest of the time just having fun. After all, isn't "fun" what these things are all about?
June 2, 2005
Test Plans #1: The Smoke Test
The first item I have in my test plans here at Ritual is the smoke test.
A smoke test is a high-level set of test cases that can be run in about 15-30 minutes that will show you whether or not the build is stable enough to be tested.
A smoke test can have three possible results.
It is important to document your smoke test for the team. It does two things. First off, it lets the team know what your minimum expectations of each build are. Second, your more ambitious colleagues can run the smoke test prior to doing any sort of check-in as a verification step.
Here is a modified version of a smoke test that I currently run (with NDA stuff removed):
1. Tester shall launch the game.
2. Tester shall drop down the console and go to [removed].
3. Tester shall use the “[removed]” cheat to give all weapons, and change the current weapon to the [removed].
4. Tester shall fire one [removed].
5. Tester shall save the game.
6. Tester shall exit.
7. Tester shall launch the game again.
8. Tester shall load the saved game, and verify that the ammo count for the [removed] is the same.
9. Tester shall fire the [removed] and [removed] to ensure that those weapons work.
10. Tester shall then go to [removed].
11. Tester shall verify that the [removed] can move, collide with [removed], and can fire.
12. Tester shall then go to [removed].
13. Tester shall again use the “[removed]” cheat.
14. Tester shall select the [removed].
15. Tester shall fire the [removed] at a wall and verify that [removed].
16. Tester shall fire the [removed] at a [removed] and verify [removed].
17. Tester shall finally attempt to load all remaining maps.
Notice that it's very straightforward. It's not an in-depth test by any stretch of the imagination, but this test can be completed in 20 minutes and in those 20 minutes, I'm exercising the entire game. If any step doesn't work, I determine if that warrants failing the build or just a note on the pass.
Now your smoke tests will not be static...they will change. It is important to update the test at least once per milestone to exercise anything that was delivered in previous milestones, or to remove tests for features that were removed, etc.
In our next installment, we'll go over the risks section.
A smoke test is a high-level set of test cases that can be run in about 15-30 minutes that will show you whether or not the build is stable enough to be tested.
A smoke test can have three possible results.
- A pass means that the build passed the smoke test without any major issues popping up.
- A pass with notes means that the build passed the majority of the smoke test, but issues popped up that wouldn't severely affect testing. For example, if during your test you find a bug that only manifests itself when you die and restart the level, that would warrant a note, but the build is still testable.
- A fail means that the build is so unstable or major functionality is so completely blocked that testing the build would be futile. A good example would be if you were testing a first person shooter, and your weapons wouldn't fire.
It is important to document your smoke test for the team. It does two things. First off, it lets the team know what your minimum expectations of each build are. Second, your more ambitious colleagues can run the smoke test prior to doing any sort of check-in as a verification step.
Here is a modified version of a smoke test that I currently run (with NDA stuff removed):
1. Tester shall launch the game.
2. Tester shall drop down the console and go to [removed].
3. Tester shall use the “[removed]” cheat to give all weapons, and change the current weapon to the [removed].
4. Tester shall fire one [removed].
5. Tester shall save the game.
6. Tester shall exit.
7. Tester shall launch the game again.
8. Tester shall load the saved game, and verify that the ammo count for the [removed] is the same.
9. Tester shall fire the [removed] and [removed] to ensure that those weapons work.
10. Tester shall then go to [removed].
11. Tester shall verify that the [removed] can move, collide with [removed], and can fire.
12. Tester shall then go to [removed].
13. Tester shall again use the “[removed]” cheat.
14. Tester shall select the [removed].
15. Tester shall fire the [removed] at a wall and verify that [removed].
16. Tester shall fire the [removed] at a [removed] and verify [removed].
17. Tester shall finally attempt to load all remaining maps.
Notice that it's very straightforward. It's not an in-depth test by any stretch of the imagination, but this test can be completed in 20 minutes and in those 20 minutes, I'm exercising the entire game. If any step doesn't work, I determine if that warrants failing the build or just a note on the pass.
Now your smoke tests will not be static...they will change. It is important to update the test at least once per milestone to exercise anything that was delivered in previous milestones, or to remove tests for features that were removed, etc.
In our next installment, we'll go over the risks section.
June 1, 2005
Why I Don't Blog Abour Ritual Much
I've had a few people ask me why I don't blog about what's going on at Ritual very often. There are two answers to that question.
First off, game development, especially on unannounced products, is a very secretive business. I can't just come out and say that we're working on this really cool *bleep* with over *bleep* new *bleep*s spread out over *bleep* new *bleeps* with *bleep bleep bleep bleep* and a sheep without stepping on some toes. All I can say is that the "Question of the Week" that I've been doing over at Ritualistic every Tuesday to solicit community feedback has contained some clues as to what we're working on, albeit minor ones.
Second, a lot of it is just plain boring. Do you really care that on Friday, I spent 90 minutes setting up and beginning to customize Issue Tracker so we can track our bugs on *bleep*, *bleep* and *bleep*?
How about how I spent 15 hours revising my test plan on *bleep*? Or 30 minutes revising my smoke test for *bleep*? Or 45 minutes examining a texture trying to decide if a corporate logo was discernable enough to warrant editing?
Fact of the matter is that a lot of the stuff I'm doing at Ritual right now is either under heavy NDA (meaning that if I even hint at it wrong, I'm in deep *bleep*), or so monotonously mundane that nobody in their right minds would care to read it. That's why I try to keep the focus of this blog on what I've learned, what I've experienced, who I am, and what I'm doing outside of Ritual.
That being said, I have learned one thing at Ritual...how to write a useful test plan. At Microsoft, test plans were these monstrous 60+ page affairs that were based off of a template, and to be quite honest, these templated pieces of shit were pretty useless. You had so much boilerplate in the way of the useful information that you really had to dig to find any information you were looking for, and because of the template, keeping it up to date and relevant got to be a bit...difficult.
So I'm going to lay out how to create a basic test plan for a video game this week. My test plan for *bleep* is only 12 pages. That includes a title/version page, one page for the table of contents, and one page for definitions.
Anyway, off to bed. I have to get up for work in seven hours.
First off, game development, especially on unannounced products, is a very secretive business. I can't just come out and say that we're working on this really cool *bleep* with over *bleep* new *bleep*s spread out over *bleep* new *bleeps* with *bleep bleep bleep bleep* and a sheep without stepping on some toes. All I can say is that the "Question of the Week" that I've been doing over at Ritualistic every Tuesday to solicit community feedback has contained some clues as to what we're working on, albeit minor ones.
Second, a lot of it is just plain boring. Do you really care that on Friday, I spent 90 minutes setting up and beginning to customize Issue Tracker so we can track our bugs on *bleep*, *bleep* and *bleep*?
How about how I spent 15 hours revising my test plan on *bleep*? Or 30 minutes revising my smoke test for *bleep*? Or 45 minutes examining a texture trying to decide if a corporate logo was discernable enough to warrant editing?
Fact of the matter is that a lot of the stuff I'm doing at Ritual right now is either under heavy NDA (meaning that if I even hint at it wrong, I'm in deep *bleep*), or so monotonously mundane that nobody in their right minds would care to read it. That's why I try to keep the focus of this blog on what I've learned, what I've experienced, who I am, and what I'm doing outside of Ritual.
That being said, I have learned one thing at Ritual...how to write a useful test plan. At Microsoft, test plans were these monstrous 60+ page affairs that were based off of a template, and to be quite honest, these templated pieces of shit were pretty useless. You had so much boilerplate in the way of the useful information that you really had to dig to find any information you were looking for, and because of the template, keeping it up to date and relevant got to be a bit...difficult.
So I'm going to lay out how to create a basic test plan for a video game this week. My test plan for *bleep* is only 12 pages. That includes a title/version page, one page for the table of contents, and one page for definitions.
Anyway, off to bed. I have to get up for work in seven hours.
Subscribe to:
Posts (Atom)