We've had a few requests from fans for the game's music files. For those who love the Keflings music and can't get enough of it, we've posted it on our website just for you! Please feel free to download (just right click on the link to download) and listen to this music for your own personal enjoyment, but remember NinjaBee owns it and retains all rights.
Opener Music
Spring Music
Summer Music
Fall Music
Winter Music
Enjoy!
Friday, March 27, 2009
Tuesday, March 24, 2009
Thank You!!!
The purpose of this post is simply to send a big 'ol thank you out to everyone who voted for A Kingdom for Keflings in the Xbox LIVE Arcade Awards. We took home the award for Best Family Game, and we couldn't have done it without all of you who voted for us!
Best Family Game of 2008
Thanks for your support!!
Best Family Game of 2008
Thanks for your support!!
Thursday, March 19, 2009
Fan Pic and Contest Result
Recently we sent some NinjaBee shirts to some friends who work at Microsoft. They not only wrote us an email saying thanks for the shirts, they sent this amazing picture to show off their shirts:
Rob and Sheridan, you guys rock! :) Props to Sheridan for creating the art!
In other cool news, remember the caption contest FreezeCracker.com held a week or so ago giving away a copy of A Kingdom for Keflings? Contestants wrote captions for the following picture and FreezeCracker picked this caption as the winner:
NinjaBee Studios will be holding a wake in honor of poor Mikey. Music will be provided by the world’s smallest violin.
Rob and Sheridan, you guys rock! :) Props to Sheridan for creating the art!
In other cool news, remember the caption contest FreezeCracker.com held a week or so ago giving away a copy of A Kingdom for Keflings? Contestants wrote captions for the following picture and FreezeCracker picked this caption as the winner:
NinjaBee Studios will be holding a wake in honor of poor Mikey. Music will be provided by the world’s smallest violin.
Wednesday, March 11, 2009
Normal Mapping and 3D Modeling Programs
[This post was written by Mike Nielsen. He is one of our designers and an avid art-class attendee (not to mention a fantastic writer). Check out his write up on the 3D Studio Max Class here]
Jeff Wiggins (one of our artists) gave an art class a few weeks ago primarily about different types of 3D modeling programs and the advantages and disadvantages of each, specifically when it comes to normal mapping. For anyone who doesn’t know, normal mapping is when you create a CRAZY detailed 3D model (with, say, 2,000,000 polygons), then apply the lighting information for said model to a low poly model (of, say, 2,000 polygons). What this does is create a model that looks remarkably like it has 2,000,000 polygons, but actually only uses 2,000 polygons worth of memory. AWESOME!
Anyway – I’m not an artist, so I may not have picked up as much as some of the other attendees did, but I CAN explain what the different programs were.
1. Mudbox. This is a program that allows the artist to create 3D models in a manner similar to how a sculptor might work with clay (or mud I guess…). It has a series of useful tools that allow the artist to push, pull, carve, texture, and otherwise shape the surface of basic geometry to create detailed and intricate models. It should be noted that Mudbox is meant to handle extremely high numbers of polygons. The mutated devil lizard that Jeff made as an example ended up having about 2,000,000 polygons when we were done with it and it was really fast to make. Jeff then showed us how to export the normal map for the lizard and import it into a different program, like 3D Studio Max.
2. Crazybump. This program is used exclusively for creating bump maps – which are similar to normal maps, but less complicated and detailed. I must say, this program was my favorite part of the class. Basically, it allows you to import a 2D image and then convert it to a bump map almost instantaneously. The example he used was with a photograph of a brick wall. He imported the photograph into the program, adjusted some settings that I can’t remember and don’t care to explain, then – ta da! Bump Map! He then applied the bump map to a cylinder (which was provided by the program) and wow – it was amazing how awesome it looked. The coolest thing was that this was all done in 5 minutes or less (excluding explanation time and questions).
3. 3D Studio Max. Jeff also busted out the good old classic 3DS Max to show us some of its normal mapping functionality. It had some really interesting features as well but it was a little more on the complicated side (in other words, I didn’t follow it nearly as well. Plus it was at the end of the class and my ADD attention span started seriously waning). He showed off “smoothing groups” functionality, which is a cool way to eliminate seams in geometry. He also walked through the process of creating a normal map using a high-poly model, then applying it to a low-poly model. It was cool to see the two models side-by-side when he was done. They were virtually identical, but one had thousands less polygons involved.
4. Photoshop. Although Photoshop wasn’t a huge part of the class, he showed us how to export grayscale images as normal maps using the Nvidia plug-in, which can then be imported into Max and applied to a 3D model. Pretty cool stuff.
Overall – I give Jeff an A+… except that he was the one teaching the class, so… whatever. Anyway, the class was awesome and I speak for all when I say that our eyes were opened to a new level of the infinite vistas of 3D asset creation.
Jeff Wiggins (one of our artists) gave an art class a few weeks ago primarily about different types of 3D modeling programs and the advantages and disadvantages of each, specifically when it comes to normal mapping. For anyone who doesn’t know, normal mapping is when you create a CRAZY detailed 3D model (with, say, 2,000,000 polygons), then apply the lighting information for said model to a low poly model (of, say, 2,000 polygons). What this does is create a model that looks remarkably like it has 2,000,000 polygons, but actually only uses 2,000 polygons worth of memory. AWESOME!
Anyway – I’m not an artist, so I may not have picked up as much as some of the other attendees did, but I CAN explain what the different programs were.
1. Mudbox. This is a program that allows the artist to create 3D models in a manner similar to how a sculptor might work with clay (or mud I guess…). It has a series of useful tools that allow the artist to push, pull, carve, texture, and otherwise shape the surface of basic geometry to create detailed and intricate models. It should be noted that Mudbox is meant to handle extremely high numbers of polygons. The mutated devil lizard that Jeff made as an example ended up having about 2,000,000 polygons when we were done with it and it was really fast to make. Jeff then showed us how to export the normal map for the lizard and import it into a different program, like 3D Studio Max.2. Crazybump. This program is used exclusively for creating bump maps – which are similar to normal maps, but less complicated and detailed. I must say, this program was my favorite part of the class. Basically, it allows you to import a 2D image and then convert it to a bump map almost instantaneously. The example he used was with a photograph of a brick wall. He imported the photograph into the program, adjusted some settings that I can’t remember and don’t care to explain, then – ta da! Bump Map! He then applied the bump map to a cylinder (which was provided by the program) and wow – it was amazing how awesome it looked. The coolest thing was that this was all done in 5 minutes or less (excluding explanation time and questions).
3. 3D Studio Max. Jeff also busted out the good old classic 3DS Max to show us some of its normal mapping functionality. It had some really interesting features as well but it was a little more on the complicated side (in other words, I didn’t follow it nearly as well. Plus it was at the end of the class and my ADD attention span started seriously waning). He showed off “smoothing groups” functionality, which is a cool way to eliminate seams in geometry. He also walked through the process of creating a normal map using a high-poly model, then applying it to a low-poly model. It was cool to see the two models side-by-side when he was done. They were virtually identical, but one had thousands less polygons involved.4. Photoshop. Although Photoshop wasn’t a huge part of the class, he showed us how to export grayscale images as normal maps using the Nvidia plug-in, which can then be imported into Max and applied to a 3D model. Pretty cool stuff.
Overall – I give Jeff an A+… except that he was the one teaching the class, so… whatever. Anyway, the class was awesome and I speak for all when I say that our eyes were opened to a new level of the infinite vistas of 3D asset creation.
Tuesday, March 10, 2009
Random, Fun, Interesting Links
Here are some cool and extremely random links to things that have popped up over the last week or so that relate (in some form or another) to NinjaBee . Enjoy!
Random Link #1: NinjaBee has a public profile and a great relationship with Gathering of Gamers, a social networking site for gamers. A few NinjaBees appeared on their GOGCast (a community podcast) season finale a few weeks ago and talked about A Kingdom for Keflings, life at NinjaBee and a few other interesting things. The podcast is pretty long, so if you just want to hear the NinjaBee stuff, it starts about 12 1/2 min. into the show. There's also a special audio clip right at the end, about 1 hour and 20 mins. into the show...:)
Random Link #2: Here's a cool YouTube video of a guy who covers XBLA songs. This rocks!
Random Link #3: Jeremy Throckmorton, one of our designers, was interviewed by Genesis Device, a cool gaming website. Check out his interview here. Here's a fun snippet from the interview (that just happens to go with the above video!):
Genesis Device: Where did the music for Kingdom come from? It's completely addictive!
Jeremy Throckmorton: Eric Nunamaker is a long time friend of ours, and a very talented composer we contract for many of our projects. We decided on a style and feel for Keflings and presented it to him. He is really, really good at making music to match our odd requests and abstract concepts. The soundtrack to Keflings is a testament to that.
Random Link #4: Michelle, the cool girl who made the A Kingdom for Keflings web comic has made a Doritos Dash of Destruction one as well.
Random Link #1: NinjaBee has a public profile and a great relationship with Gathering of Gamers, a social networking site for gamers. A few NinjaBees appeared on their GOGCast (a community podcast) season finale a few weeks ago and talked about A Kingdom for Keflings, life at NinjaBee and a few other interesting things. The podcast is pretty long, so if you just want to hear the NinjaBee stuff, it starts about 12 1/2 min. into the show. There's also a special audio clip right at the end, about 1 hour and 20 mins. into the show...:)
Random Link #2: Here's a cool YouTube video of a guy who covers XBLA songs. This rocks!
Random Link #3: Jeremy Throckmorton, one of our designers, was interviewed by Genesis Device, a cool gaming website. Check out his interview here. Here's a fun snippet from the interview (that just happens to go with the above video!):
Genesis Device: Where did the music for Kingdom come from? It's completely addictive!
Jeremy Throckmorton: Eric Nunamaker is a long time friend of ours, and a very talented composer we contract for many of our projects. We decided on a style and feel for Keflings and presented it to him. He is really, really good at making music to match our odd requests and abstract concepts. The soundtrack to Keflings is a testament to that.
Random Link #4: Michelle, the cool girl who made the A Kingdom for Keflings web comic has made a Doritos Dash of Destruction one as well.
Tuesday, March 03, 2009
Vote for A Kingdom for Keflings!
Microsoft is hosting its second annual Xbox LIVE Arcade Awards highlighting Arcade games released in 2008. A Kingdom for Keflings has been nominated for two categories--Best Family Game and Best Innovation in XBLA--and we need your help! Please take a minute to follow the instructions below to vote for the games you think should win. Voting takes place through your Xbox 360 console and ends March 10 at 4 p.m., so vote as soon as you can! Thanks for your help!
How to Vote:
1. From your Xbox LIVE console, locate the Arcade Awards Voting Application slot in the Spotlight or Game Marketplace channel, and then press A to download the application.
2. Once the application has finished downloading, launch the application.
3. Select your favorite arcade game in any or all of the nine different categories, and then select the appropriate button below:
* To vote, press A.
* To view game screenshots, press X.
* To download the game demo, press Y.
* To exit, press B.
[instructions from Xbox.com]
Monday, March 02, 2009
Testing, Testing...
[This blog post was written by Taylor Eshelman, one of our artists (and sometimes testers)]
My job description is "artist." I bill myself as a "technical artist" since I have a technologically savvy streak. I've even branched out into design here and there, most notably in an extracurricular collaboration project that's a variant of the "game in a day" that we did a while back. Today, though, I'm a tester.
Yessiree, I'm a QA drone. I've argued it before, and I'll do so again: Game testers don't get anywhere near enough credit for what they do.
In many ways, the QA (Quality Assurance) people are the last line of defense in game development. It's nearly impossible to ship a game with absolutely no bugs, but games that ship with egregious problems fail quickly and may never recover. Vanguard had a terrible launch, but has since been polished and refined into a much better game. Even so, that initial impression of a game that was literally broken in several ways has lingered, killing the early adopter buzz which can be so crucial for hitting sales targets. Gamers can be terribly fickle and judgmental, and a poor first impression (or a bad early review or two) can sink a game, whether that impression is well deserved or not, and whether or not real complaints are addressed adequately. As in so many other aspects of life, a "best foot forward" approach is crucial for games.
QA testers are the safety net for the game development process. There are so many cogs and fiddly bits that come together in any software project that there will almost inevitably be things that don't mesh well. The only way to find many of these problems is to play the game. Over and over. And over and over.
You see, game testing QA isn't very similar to the end user experience. QA people have to repeat the same procedures many times, trying to suss out how things might break. They actively try to break the game, which can include doing normal "gamer" things, and more, by doing really weird stuff. (You know that someone out there will do something so totally wacky with your game that they will break it in ways you never would have thought to test... but you still try to test as much as you can to head them off at the pass.)
That's inherently different from trying to "beat" a game. QA people do have to keep the concept of "fun" in the back of their mind, and notions like "balance" and "emergent gameplay," but for the most part, testing means actively trying to find *problems* in a product, not trying to find *fun*. That's why it's a job, and why it takes unique skills. That's not to say that "gamers" can't also be testers, just that the two aren't equivalent.
The writers over at the Elder Game blog rightfully point out that QA isn't something that is best done in a vacuum. Testers need to know how the game is expected to work, in order to try to break it. That may seem obvious, but it's an application of the "thinking outside of the box" cliche: in order to try to stretch an idea or game outside of its box, you have to know where the box is in the first place. The Elder Game article describes this in more depth, so I highly recommend popping over there to see what they have to say. Long story short, the designers, engineers and artists need to work with the QA department to make sure they have the tools and expectations to properly put the game through its paces. (The old "It's a feature, not a bug!" argument after the fact doesn't work all that well.)
Yes, ultimately it's the engineers and artists that create the content and string it all together into a coherent package, but they will inevitably mess something up. We aren't perfect. We're relying on testers to catch the things that we missed. We certainly self-test a fair dose of things, but sometimes bugs don't even show up until things start coming together. The project that I've been working on has unique bugs that show up when the code goes from the PC where I worked on the content to the final game platform (a different bit of hardware). I'll never see certain problems testing things on the PC, despite doing all I can as an artist to make things correctly and test them before committing changes to the database.
Even in an age of "ship now, patch later", good QA is vital to getting things as right as possible for the initial release. Games are such transient bits of entertainment that a buggy product can totally miss the window of opportunity on the market, even if it's fixed later. As such, good testers are often a key component to financial success (between content creation/coding and marketing), which, at the end of the day, is what keeps food on the table.
Game development is an organic process with a lot of give and take. QA is a crucial component of that refinement process, and I, for one, find a great deal of responsibility in the role, and a great deal of appreciation for those intrepid souls who do it day in and day out, often toiling with little recognition.
-Tesh
My job description is "artist." I bill myself as a "technical artist" since I have a technologically savvy streak. I've even branched out into design here and there, most notably in an extracurricular collaboration project that's a variant of the "game in a day" that we did a while back. Today, though, I'm a tester.
Yessiree, I'm a QA drone. I've argued it before, and I'll do so again: Game testers don't get anywhere near enough credit for what they do.
In many ways, the QA (Quality Assurance) people are the last line of defense in game development. It's nearly impossible to ship a game with absolutely no bugs, but games that ship with egregious problems fail quickly and may never recover. Vanguard had a terrible launch, but has since been polished and refined into a much better game. Even so, that initial impression of a game that was literally broken in several ways has lingered, killing the early adopter buzz which can be so crucial for hitting sales targets. Gamers can be terribly fickle and judgmental, and a poor first impression (or a bad early review or two) can sink a game, whether that impression is well deserved or not, and whether or not real complaints are addressed adequately. As in so many other aspects of life, a "best foot forward" approach is crucial for games.
QA testers are the safety net for the game development process. There are so many cogs and fiddly bits that come together in any software project that there will almost inevitably be things that don't mesh well. The only way to find many of these problems is to play the game. Over and over. And over and over.
You see, game testing QA isn't very similar to the end user experience. QA people have to repeat the same procedures many times, trying to suss out how things might break. They actively try to break the game, which can include doing normal "gamer" things, and more, by doing really weird stuff. (You know that someone out there will do something so totally wacky with your game that they will break it in ways you never would have thought to test... but you still try to test as much as you can to head them off at the pass.)
That's inherently different from trying to "beat" a game. QA people do have to keep the concept of "fun" in the back of their mind, and notions like "balance" and "emergent gameplay," but for the most part, testing means actively trying to find *problems* in a product, not trying to find *fun*. That's why it's a job, and why it takes unique skills. That's not to say that "gamers" can't also be testers, just that the two aren't equivalent.
The writers over at the Elder Game blog rightfully point out that QA isn't something that is best done in a vacuum. Testers need to know how the game is expected to work, in order to try to break it. That may seem obvious, but it's an application of the "thinking outside of the box" cliche: in order to try to stretch an idea or game outside of its box, you have to know where the box is in the first place. The Elder Game article describes this in more depth, so I highly recommend popping over there to see what they have to say. Long story short, the designers, engineers and artists need to work with the QA department to make sure they have the tools and expectations to properly put the game through its paces. (The old "It's a feature, not a bug!" argument after the fact doesn't work all that well.)
Yes, ultimately it's the engineers and artists that create the content and string it all together into a coherent package, but they will inevitably mess something up. We aren't perfect. We're relying on testers to catch the things that we missed. We certainly self-test a fair dose of things, but sometimes bugs don't even show up until things start coming together. The project that I've been working on has unique bugs that show up when the code goes from the PC where I worked on the content to the final game platform (a different bit of hardware). I'll never see certain problems testing things on the PC, despite doing all I can as an artist to make things correctly and test them before committing changes to the database.
Even in an age of "ship now, patch later", good QA is vital to getting things as right as possible for the initial release. Games are such transient bits of entertainment that a buggy product can totally miss the window of opportunity on the market, even if it's fixed later. As such, good testers are often a key component to financial success (between content creation/coding and marketing), which, at the end of the day, is what keeps food on the table.
Game development is an organic process with a lot of give and take. QA is a crucial component of that refinement process, and I, for one, find a great deal of responsibility in the role, and a great deal of appreciation for those intrepid souls who do it day in and day out, often toiling with little recognition.
-Tesh
Subscribe to:
Posts (Atom)