Just like with the A Kingdom for Keflings music, we've had a few requests for the Outpost Kaloki music. So here's the riff that is present in the main game and also in the iPhone/iPod touch version that was just released, Kaloki Adventure. And again, 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.
Kaloki Swing
Wednesday, May 13, 2009
Tuesday, May 05, 2009
Indie Game Night
Utah Indie Game Night is held once a quarter, and because we're part of the indie scene here in Utah, we host it at our offices every once in a while. Last Thursday we had about 40 people show up for the evening of fun and games. Eric Pattison, one of our programmers, attended with some of his ITT students, and here's what he had to say about the night:
"Indie Game night had a great turnout, with a lot of great projects shown, a wonderful presentation by Darius Ouderkirk on 'Choosing an indie game project wisely, so that it increases your chances of finishing it,' and an abundance of pizza."
Sadly, we didn't get any pictures of the event, but if you can imagine a room with 20 Papa John's pizzas and 40 programmers/designers/artists, you can imagine a room with a lot of smiling faces :)
If you want to read more detailed descriptions of the night's events, go to Jay Barnson's blog or Greg Squire's blog. Also, the slides from the presentation can be found here and the first part of Darius' presentation can be found on his blog, here.
"Indie Game night had a great turnout, with a lot of great projects shown, a wonderful presentation by Darius Ouderkirk on 'Choosing an indie game project wisely, so that it increases your chances of finishing it,' and an abundance of pizza."
Sadly, we didn't get any pictures of the event, but if you can imagine a room with 20 Papa John's pizzas and 40 programmers/designers/artists, you can imagine a room with a lot of smiling faces :)
If you want to read more detailed descriptions of the night's events, go to Jay Barnson's blog or Greg Squire's blog. Also, the slides from the presentation can be found here and the first part of Darius' presentation can be found on his blog, here.
Monday, April 27, 2009
iPhone Lessons
For the past few months, a few of our team members have been working on adapting Outpost Kaloki to the iPhone/iPod touch. This was our first attempt at developing for the iPhone, and we definitely learned a few things along the way. Since developing games for the iPhone has become so popular, we thought we’d share the lessons we’ve learned to make things easier for those thinking of converting an existing game or starting from scratch on iPhone development. We asked each team member a series of questions relating to their role in the project. We’ll start with programming, then move to art/animation, then design, and finish off with testing. If you have any questions you want the team to answer, leave them in the comments and we’ll write up a separate post to answer those questions.
Kevin--Programmer
1. Describe the level of difficulty in converting an XBLA game to the iPhone.
Converting the game proved to be much more difficult than I had anticipated so I'm going to have to classify it as "hard."
2. What things really tripped you up in the development process? What was surprisingly easy?
We ended up converting pretty much our entire Wraith game engine over to the iPhone which proved to be quite troublesome. This was problematic for a couple of key reasons. First of all, the iPhone SDK is written in a different language than Wraith. Fortunately we were able to "glue" the two together but it made things a bit messy. Secondly, our engine is used to owning complete control over inputs and external systems. The iPhone likes to own all those things and to update them on its own and tell you about events that happen. Eventually we ended up letting the iPhone do its thing on one thread while the game ran on a separate thread and the threads communicated together about input and events, etc.
Another thing that tripped us up during development was the difference in power between the Xbox and the iPhone hardware. I don't think we really had a good feel for what the iPhone could handle graphically and we were simply trying to give it too much to do and it was choking. Once we had a better feel for the hardware capabilities we were able to tone down a few systems from the Xbox and give the user a decent playable experience.
I'm not sure that anything really turned out to be surprisingly easy - the whole experience felt like it would be easier than it actually turned out to be.
3. How long did you originally estimate development would take? How long did it actually take start to finish (not counting submission to apple)? Why the disparity in time?
I thought it would take 1-2 months originally and it's turned out to be closer to 3-4 months. The disparity in time was due to the unanticipated engine conversion difficulty.
4. What are the biggest differences between developing for XBLA vs. PC vs. iPhone?
Our game engine is written to be platform independent, which makes it so we can pretty much make the game in one platform and the low level functionality is hidden. This way, once the engine is converted to whatever platform (the iPhone in this case), everything just works. Of course, this is what happens in a perfect world. The conversion of the engine to the iPhone turned out to be quite challenging, but it didn't change the gameplay much at all. You're really getting pretty much the same game you played on XBLA now on the iPhone.
5. What advice can you give anyone developing for the iphone?
If you've never developed for the iPhone, spend some time getting familiar with the capabilities of the hardware and plan plenty of time to get used to the unfamiliar API.
Taylor--Artist
1. What was it like converting the art from an XBLA game to an iPhone game? Was it harder or easier than you expected?
Converting art assets from an XBLA game to the iPod/iPhone was an exercise in amputation, a stress test of the "reduce, reuse, recycle" mantra that ultimately prompted the class that I gave regarding the texturing and UV pipeline (see blog post here).
Game design in general is very different from the Pixar-style art generation that I trained for in college, and we're always trying to shoehorn as much as we can into every byte we have. Specifically when taking game assets from the Xbox to the iPod/iPhone, we had to reduce poly count and texture footprint by as much as 98%.
There wasn't anything terribly hard about converting the assets, but there were many little choices about how to reduce the models and textures, and everything required unique attention. A simple macro script wouldn't be enough to make it work well. This was expected, but it did wind up taking longer than expected because of iterative testing and some extensive model alteration, reconstruction and re-texturing as tech specs changed.
2. What was the biggest challenge in working on the art? The most surprisingly easy thing?
The biggest challenge working with such drastically reduced asset budgets was to maintain a look and feel consistent with the original game. That meant making cuts that really matter, but look like they don't. I think that overall, we've been able to make the game look and play enough like its progenitor that it captures the fun of the original without making too many sacrifices.
Maintaining the look and feel of the environments was surprisingly easy, given the complexity of the originals. It turned out that there were a ton of superfluous polygons in the models, so even a quick optimization pass got us a fair chunk of the way to where we wanted to be. A few texturing tricks later, and we had environments of 120 polygons or so that were less sumptuous than the originals, but still set the mood well. The originals were over 3000 polys in some cases, so we got a lot of value out of those 120 polys. We were also able to reuse those assets a lot easier than ship or station assets, so the environments went very, very quickly compared to the rest of the conversion.
3. What changes did you have to make to get the art to work on the iPhone? Did you create anything new?
We made several new LODs (Level of Detail meshes) for the ships and station expansions. We also wound up making a few new textures to fill in gaps or to optimize visuals that were fairly loose in the original. Everything was "under the hood" though, since there were no new ships, stations or expansions added. Anything new we made was just a tool to make the game look right (like the original) in the iPod/iPhone format.
Paradoxically, considering the vast reductions elsewhere, I actually wound up making larger versions of some HUD (Heads-Up Display) elements. The loss of precision that comes with switching from a mouse cursor to a touch input scheme meant that we had to alter some of the game UI. Even there, though, it was just making "technically new" visuals to approximate the old visuals.
4. Any advice you would give to someone working as an artist/animator for an iPhone game?
Get your game running on the iPod/iPhone as quickly as possible, and make sure the art and engineering teams work together to optimize it. The hardware chokes on things that larger consoles handle easily, and the earlier you can nail down target specs, the sooner you can get productive work done. We lost a lot of time by starting the project without an engineer and without the game actually functioning on the hardware. We did reduce assets, but after we started testing them, we needed to do another reduction pass (sometimes a couple of reduction passes) because the vague guesstimates we did early on weren't stringent enough, and the assets choked the iPod/iPhone, even though they were reduced to 25% of the original size. This reworking took a lot of time that could have been saved with clearer reduction targets early on, and early testing with engineering guidance would have helped define those targets.
Ben--Designer
1. What was it like converting the design elements from an XBLA game to an iPhone game? Was it harder or easier than you expected?
I didn't really know what to expect in converting this game to the iPhone! I have never worked on or owned an iPhone, so, it was all new to me. I didn't imagine it being very difficult but there were many things I just didn't think about until it actually came time to start making tweaks on the iPhone. For one, the screen was very crowded. We had to make numerous revisions to the UI because important parts were being covered or because our clumsy fingers couldn't navigate the game very well.
2. What was the biggest challenge in working on the design? The most surprisingly easy thing?
The biggest challenge that I was faced with had to be figuring out what to keep in the game and what to get rid of. We imposed a very strict limitation on the size that the game could be and this meant we had to be conservative with what made the final cut. Fortunately, no gameplay was lost due to these cuts but we did have to remove some of the really cool ships that only appeared once or twice in the whole game.
I was assigned the task of cutting down the size of audio files in the game to save us some more space. If you were to play the games side-by-side you might notice a little difference in the sound. Fortunately, we were able to save plenty of space by cutting down the sound files, yet, the sound is still awesome in the game.
The easiest thing was probably shouting at Kevin every time the game crashed - even when it wasn't his fault. :)
3. What changes did you have to make to the design to get it to work on the iphone?
When shrinking the screens down to fit on the iPhone screen there were a lot of things initially that just looked terrible. There was plenty of shuffling around of pieces of art on the screen, as well as text. Some of the text which fit perfectly on the XBLA version bled a horrible death all over the screen on the iPhone.
We also had tons of awesome content that we wanted iPhone users to be able to access. Unfortunately, there was just too much content for it all to go in one game. Deciding how to split up the content to make it balanced fell primarily on Jeremy's shoulders, I believe. Jeremy worked on the game originally and was much more familiar with it than I was.
4. Any advice you would give to someone working as a designer for an iPhone game?
If I were to give a designer of an iPhone game any advice it would be a warning: Remember that people have fat fingers (or at least I do anyways)! All actions in the game should easily be performed by someone who has really fat fingers! Even if your game is called "Uber kool game 4 ppl w/thin fingerz" it should still adhere to this rule.
Jason--Tester
1. What was it like testing for an iPhone game? Was it harder or easier than you expected?
Testing on an iPhone is like testing in the future! It’s all shiny, smooth, and full of lights. Testing on it was pretty much what I expected, there’s a quick period of adjustment to adapt to the console and UI in pretty much every project.
2. What was the biggest challenge in testing? The most surprisingly easy thing?
The biggest challenge for me in any testing gig is just testing around bugs. For instance if there’s a lot of lag on a level it makes it very difficult to test the level effectively.
3. What crazy bugs did you come across that happened because of converting from XBLA to iPhone?
In one scenario asteroids are suppose to bombard the station, but something happened to the graphics and sound so they were silent and invisible. So I’d be playing and everything would be going along just fine, and then all of sudden half of the expansions on my station would just explode.
In the War Story scenario, war ships are supposed to come in and attack your expansion. When you destroy them, it helps you earn money and complete the mission. However, at one point in the game, the attackers would come in, hover around an expansion, then fly off without attacking. You could destroy the war ships but it wouldn’t count, which made it so you couldn’t pass the level.
4. Any advice you would give to someone working as a tester for an iPhone game?
Learn a couple of deep breathing techniques to calm down for those unavoidable times you’ll want to throw the thing across the room.
Kevin--Programmer
1. Describe the level of difficulty in converting an XBLA game to the iPhone.
Converting the game proved to be much more difficult than I had anticipated so I'm going to have to classify it as "hard."
2. What things really tripped you up in the development process? What was surprisingly easy?
We ended up converting pretty much our entire Wraith game engine over to the iPhone which proved to be quite troublesome. This was problematic for a couple of key reasons. First of all, the iPhone SDK is written in a different language than Wraith. Fortunately we were able to "glue" the two together but it made things a bit messy. Secondly, our engine is used to owning complete control over inputs and external systems. The iPhone likes to own all those things and to update them on its own and tell you about events that happen. Eventually we ended up letting the iPhone do its thing on one thread while the game ran on a separate thread and the threads communicated together about input and events, etc.
Another thing that tripped us up during development was the difference in power between the Xbox and the iPhone hardware. I don't think we really had a good feel for what the iPhone could handle graphically and we were simply trying to give it too much to do and it was choking. Once we had a better feel for the hardware capabilities we were able to tone down a few systems from the Xbox and give the user a decent playable experience.
I'm not sure that anything really turned out to be surprisingly easy - the whole experience felt like it would be easier than it actually turned out to be.
3. How long did you originally estimate development would take? How long did it actually take start to finish (not counting submission to apple)? Why the disparity in time? I thought it would take 1-2 months originally and it's turned out to be closer to 3-4 months. The disparity in time was due to the unanticipated engine conversion difficulty.
4. What are the biggest differences between developing for XBLA vs. PC vs. iPhone?
Our game engine is written to be platform independent, which makes it so we can pretty much make the game in one platform and the low level functionality is hidden. This way, once the engine is converted to whatever platform (the iPhone in this case), everything just works. Of course, this is what happens in a perfect world. The conversion of the engine to the iPhone turned out to be quite challenging, but it didn't change the gameplay much at all. You're really getting pretty much the same game you played on XBLA now on the iPhone.
5. What advice can you give anyone developing for the iphone?
If you've never developed for the iPhone, spend some time getting familiar with the capabilities of the hardware and plan plenty of time to get used to the unfamiliar API.Taylor--Artist
1. What was it like converting the art from an XBLA game to an iPhone game? Was it harder or easier than you expected?
Converting art assets from an XBLA game to the iPod/iPhone was an exercise in amputation, a stress test of the "reduce, reuse, recycle" mantra that ultimately prompted the class that I gave regarding the texturing and UV pipeline (see blog post here).
Game design in general is very different from the Pixar-style art generation that I trained for in college, and we're always trying to shoehorn as much as we can into every byte we have. Specifically when taking game assets from the Xbox to the iPod/iPhone, we had to reduce poly count and texture footprint by as much as 98%.
There wasn't anything terribly hard about converting the assets, but there were many little choices about how to reduce the models and textures, and everything required unique attention. A simple macro script wouldn't be enough to make it work well. This was expected, but it did wind up taking longer than expected because of iterative testing and some extensive model alteration, reconstruction and re-texturing as tech specs changed.
2. What was the biggest challenge in working on the art? The most surprisingly easy thing?The biggest challenge working with such drastically reduced asset budgets was to maintain a look and feel consistent with the original game. That meant making cuts that really matter, but look like they don't. I think that overall, we've been able to make the game look and play enough like its progenitor that it captures the fun of the original without making too many sacrifices.
Maintaining the look and feel of the environments was surprisingly easy, given the complexity of the originals. It turned out that there were a ton of superfluous polygons in the models, so even a quick optimization pass got us a fair chunk of the way to where we wanted to be. A few texturing tricks later, and we had environments of 120 polygons or so that were less sumptuous than the originals, but still set the mood well. The originals were over 3000 polys in some cases, so we got a lot of value out of those 120 polys. We were also able to reuse those assets a lot easier than ship or station assets, so the environments went very, very quickly compared to the rest of the conversion.
3. What changes did you have to make to get the art to work on the iPhone? Did you create anything new?
We made several new LODs (Level of Detail meshes) for the ships and station expansions. We also wound up making a few new textures to fill in gaps or to optimize visuals that were fairly loose in the original. Everything was "under the hood" though, since there were no new ships, stations or expansions added. Anything new we made was just a tool to make the game look right (like the original) in the iPod/iPhone format.
Paradoxically, considering the vast reductions elsewhere, I actually wound up making larger versions of some HUD (Heads-Up Display) elements. The loss of precision that comes with switching from a mouse cursor to a touch input scheme meant that we had to alter some of the game UI. Even there, though, it was just making "technically new" visuals to approximate the old visuals.
4. Any advice you would give to someone working as an artist/animator for an iPhone game?
Get your game running on the iPod/iPhone as quickly as possible, and make sure the art and engineering teams work together to optimize it. The hardware chokes on things that larger consoles handle easily, and the earlier you can nail down target specs, the sooner you can get productive work done. We lost a lot of time by starting the project without an engineer and without the game actually functioning on the hardware. We did reduce assets, but after we started testing them, we needed to do another reduction pass (sometimes a couple of reduction passes) because the vague guesstimates we did early on weren't stringent enough, and the assets choked the iPod/iPhone, even though they were reduced to 25% of the original size. This reworking took a lot of time that could have been saved with clearer reduction targets early on, and early testing with engineering guidance would have helped define those targets.
Ben--Designer
1. What was it like converting the design elements from an XBLA game to an iPhone game? Was it harder or easier than you expected?
I didn't really know what to expect in converting this game to the iPhone! I have never worked on or owned an iPhone, so, it was all new to me. I didn't imagine it being very difficult but there were many things I just didn't think about until it actually came time to start making tweaks on the iPhone. For one, the screen was very crowded. We had to make numerous revisions to the UI because important parts were being covered or because our clumsy fingers couldn't navigate the game very well.
2. What was the biggest challenge in working on the design? The most surprisingly easy thing?
The biggest challenge that I was faced with had to be figuring out what to keep in the game and what to get rid of. We imposed a very strict limitation on the size that the game could be and this meant we had to be conservative with what made the final cut. Fortunately, no gameplay was lost due to these cuts but we did have to remove some of the really cool ships that only appeared once or twice in the whole game.
I was assigned the task of cutting down the size of audio files in the game to save us some more space. If you were to play the games side-by-side you might notice a little difference in the sound. Fortunately, we were able to save plenty of space by cutting down the sound files, yet, the sound is still awesome in the game.
The easiest thing was probably shouting at Kevin every time the game crashed - even when it wasn't his fault. :)
3. What changes did you have to make to the design to get it to work on the iphone?
When shrinking the screens down to fit on the iPhone screen there were a lot of things initially that just looked terrible. There was plenty of shuffling around of pieces of art on the screen, as well as text. Some of the text which fit perfectly on the XBLA version bled a horrible death all over the screen on the iPhone.
We also had tons of awesome content that we wanted iPhone users to be able to access. Unfortunately, there was just too much content for it all to go in one game. Deciding how to split up the content to make it balanced fell primarily on Jeremy's shoulders, I believe. Jeremy worked on the game originally and was much more familiar with it than I was. 4. Any advice you would give to someone working as a designer for an iPhone game?
If I were to give a designer of an iPhone game any advice it would be a warning: Remember that people have fat fingers (or at least I do anyways)! All actions in the game should easily be performed by someone who has really fat fingers! Even if your game is called "Uber kool game 4 ppl w/thin fingerz" it should still adhere to this rule.
Jason--Tester
1. What was it like testing for an iPhone game? Was it harder or easier than you expected?
Testing on an iPhone is like testing in the future! It’s all shiny, smooth, and full of lights. Testing on it was pretty much what I expected, there’s a quick period of adjustment to adapt to the console and UI in pretty much every project.
2. What was the biggest challenge in testing? The most surprisingly easy thing?
The biggest challenge for me in any testing gig is just testing around bugs. For instance if there’s a lot of lag on a level it makes it very difficult to test the level effectively.
3. What crazy bugs did you come across that happened because of converting from XBLA to iPhone?
In one scenario asteroids are suppose to bombard the station, but something happened to the graphics and sound so they were silent and invisible. So I’d be playing and everything would be going along just fine, and then all of sudden half of the expansions on my station would just explode.
In the War Story scenario, war ships are supposed to come in and attack your expansion. When you destroy them, it helps you earn money and complete the mission. However, at one point in the game, the attackers would come in, hover around an expansion, then fly off without attacking. You could destroy the war ships but it wouldn’t count, which made it so you couldn’t pass the level.
4. Any advice you would give to someone working as a tester for an iPhone game?
Learn a couple of deep breathing techniques to calm down for those unavoidable times you’ll want to throw the thing across the room.
Thursday, April 09, 2009
NinjaBee games now on Amazon!
(So, this should have been a quick and easy post with a link to our Amazon page, but it's turned into a rambling paragraph on the coolness of this service and all else in between. You decide if you want to read the whole thing. If you don't, I don't blame you. Here's the link to the NinjaBee Amazon page, and the XBLA Amazon page. If you do read the whole thing, leave a comment so I can know how cool you are :))
Wow, this is pretty cool. Now you can buy all of our Xbox LIVE Arcade games (and most other Arcade games) on Amazon.com! This is exceptionally sweet because you can use real money and you can gift the game to anyone via email. In my opinion, this makes it tons easier for anyone to buy a game.
For instance, let's say grandma wants to buy some games for her grandkids. Before they were on Amazon, she had to own a console (well, the grandkids' console, really) and buy Microsoft Points so she could pay for the games and then she had to figure out how to download them to the console. Things got a bit easier thanks to the NXE updates, when granny could buy the games online, but only if she knew the account and password of her grandkids' accounts to use the online marketplace and buy the games, where she still had to convert her real money into Microsoft Points (which she probably didn't understand and definitely wouldn't use again). Now, however, she simply goes to Amazon.com, types in the game she wants to buy, enters her payment information, and it spits out a code she then sends via email to her grandkids by pushing the "Send as a Gift" button once she's purchased the game. The grateful (and probably shocked) grandkids then enter the code into their Xbox 360 and Voila! They have the game!
Here's what our NinjaBee page looks like on Amazon.com:
I bought a copy of A Kingdom for Keflings yesterday to try it out and it's incredibly easy; no extra hoops to fly through, only the normal Amazon procedure. In fact, it was so easy, I accidentally purchased a copy--I only wanted to go through the steps up to the purchase page, but there were so few steps I over-estimated and ended up buying a copy. Have you tried it yet? What are your thoughts?
Wow, this is pretty cool. Now you can buy all of our Xbox LIVE Arcade games (and most other Arcade games) on Amazon.com! This is exceptionally sweet because you can use real money and you can gift the game to anyone via email. In my opinion, this makes it tons easier for anyone to buy a game.
For instance, let's say grandma wants to buy some games for her grandkids. Before they were on Amazon, she had to own a console (well, the grandkids' console, really) and buy Microsoft Points so she could pay for the games and then she had to figure out how to download them to the console. Things got a bit easier thanks to the NXE updates, when granny could buy the games online, but only if she knew the account and password of her grandkids' accounts to use the online marketplace and buy the games, where she still had to convert her real money into Microsoft Points (which she probably didn't understand and definitely wouldn't use again). Now, however, she simply goes to Amazon.com, types in the game she wants to buy, enters her payment information, and it spits out a code she then sends via email to her grandkids by pushing the "Send as a Gift" button once she's purchased the game. The grateful (and probably shocked) grandkids then enter the code into their Xbox 360 and Voila! They have the game!
Here's what our NinjaBee page looks like on Amazon.com:
I bought a copy of A Kingdom for Keflings yesterday to try it out and it's incredibly easy; no extra hoops to fly through, only the normal Amazon procedure. In fact, it was so easy, I accidentally purchased a copy--I only wanted to go through the steps up to the purchase page, but there were so few steps I over-estimated and ended up buying a copy. Have you tried it yet? What are your thoughts?
Wednesday, April 01, 2009
April Fool's!
April Fool's Day is usually lots of fun around here. Last year we all came in to discover our desks, and everything on them, had been covered in aluminum foil. I wish I had taken pictures, but alas, you'll just have to imagine the funniness of it.
So this year, I'm walking in to the office with Lane and I say to him, "Do you think everything is covered in foil?" and he has a quizzical look on his face. I remind him it's April Fool's and he sighs heavily, "Oh boy, I wonder what happened this year." So we walk in the door and see a ladder leaning against the elevator. "I wonder what they needed a ladder for?" Lane says. "That," I say:
Someone had moved Mike's entire desk to the small ledge above the front door. They moved his monitor, computer, his trinkets and pictures--they even bothered to connect his computer to the internet!
It was pretty awesome. Thinking this was the only April Fool's joke, I walk into my office only to discover I, too, had been pranked:
Everything I have hung around my desk--pictures, posters, comics, articles, calendar--had been pinned upside down. I practically got vertigo looking around at everything on my walls! I had a good laugh about that one. I have to give props to the April Fool's Fairy; I think he (or she) did a pretty good job this year. I don't care what other people say; I like April Fool's Day :)
So this year, I'm walking in to the office with Lane and I say to him, "Do you think everything is covered in foil?" and he has a quizzical look on his face. I remind him it's April Fool's and he sighs heavily, "Oh boy, I wonder what happened this year." So we walk in the door and see a ladder leaning against the elevator. "I wonder what they needed a ladder for?" Lane says. "That," I say:
Someone had moved Mike's entire desk to the small ledge above the front door. They moved his monitor, computer, his trinkets and pictures--they even bothered to connect his computer to the internet!
It was pretty awesome. Thinking this was the only April Fool's joke, I walk into my office only to discover I, too, had been pranked:
Everything I have hung around my desk--pictures, posters, comics, articles, calendar--had been pinned upside down. I practically got vertigo looking around at everything on my walls! I had a good laugh about that one. I have to give props to the April Fool's Fairy; I think he (or she) did a pretty good job this year. I don't care what other people say; I like April Fool's Day :)
Friday, March 27, 2009
A Kingdom for Keflings Music
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!
Opener Music
Spring Music
Summer Music
Fall Music
Winter Music
Enjoy!
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
Friday, February 27, 2009
Intro to 3D Studio Max Class
[This post was written by one of our designers, Mike Nielson. Thanks Mike!]
The teacher for this class was the lovely Shannon Blitz, one of our artists. Basically, NinjaBee decided to do this class, per Shannon’s request, as a response to designers and programmers ALWAYS having to ask artists to make temp art for them when the artists have better things to do. In Shannon’s own words, “laziness” was the motivation for this class.
The class basically covered the basics of how to create simple 3D objects in 3D Studio Max. We started by talking about how to create what are called “standard primitives” – shapes like boxes, cones, cylinders, etc. Next we talked about how to edit said shapes. This included rotating, moving, sizing, distorting, mirroring, etc. We also talked about how to attach simple objects together to make more complex objects.
The next phase of the class was a low-level rundown of how to texture (apply color to) an object. We pulled out the materials editor, unwrapped our UVWs and went to town. It was most informative.
Finally we discussed how to export objects from Max into game projects. She showed us step-by-step how to export objects from max using the NinjaBee exporters. She also walked through how to put .png textures into projects and how to get objects showing up in the game viewer.
It was a pretty awesome class for designers, programmers, and others that have had little exposure to the labyrinthine miasma that is called 3D Studio Max. The basics were covered nicely and I think that I and my fellow designers/programmers are much closer to creating ugly temp art of our very own to be used in future games.
The teacher for this class was the lovely Shannon Blitz, one of our artists. Basically, NinjaBee decided to do this class, per Shannon’s request, as a response to designers and programmers ALWAYS having to ask artists to make temp art for them when the artists have better things to do. In Shannon’s own words, “laziness” was the motivation for this class.
The class basically covered the basics of how to create simple 3D objects in 3D Studio Max. We started by talking about how to create what are called “standard primitives” – shapes like boxes, cones, cylinders, etc. Next we talked about how to edit said shapes. This included rotating, moving, sizing, distorting, mirroring, etc. We also talked about how to attach simple objects together to make more complex objects.
The next phase of the class was a low-level rundown of how to texture (apply color to) an object. We pulled out the materials editor, unwrapped our UVWs and went to town. It was most informative.
Finally we discussed how to export objects from Max into game projects. She showed us step-by-step how to export objects from max using the NinjaBee exporters. She also walked through how to put .png textures into projects and how to get objects showing up in the game viewer.
It was a pretty awesome class for designers, programmers, and others that have had little exposure to the labyrinthine miasma that is called 3D Studio Max. The basics were covered nicely and I think that I and my fellow designers/programmers are much closer to creating ugly temp art of our very own to be used in future games.
Wednesday, February 25, 2009
Texture Optimization Class
Last Friday one of our artists, Taylor Eshelman, gave an excellent, in-depth class on texture mapping using 3DS Max and how to optimize it for a production pipeline. For those who are interested, here are the basic speaking points from his class (written by him):
1. Plan Ahead: Without a fairly clear idea of where you're going to want to wind up, you will waste a lot of time, and will probably wind up wasting vertices, pixels or both.
2. Reduce, Reuse, Recycle: We can and should recycle art assets when working in CG, not only because we can, but because it can reduce development time, asset generation and maintenance, and project data footprint. We should use the idea of "object oriented" texturing where possible.
3. Making the Most of Assets: A consistent philosophy of optimization will often mean the difference between high polish and "good enough", especially if you can squeeze in that last cool visual because your optimization strategy made room for it.
4. Vertex Count vs. Pixel Count and Tileability: Making the most out of assets will often mean finding ways to use the model, texture and vertex color (and maybe normals) together to produce effects that might otherwise be done independently, and more expensively. Tiling textures may get a lot more mileage with careful modeling. Every pixel and vertex needs a reason for existing.
5. Waste vs. Warp: Warping things this way can reduce the waste that comes from UV mapping anything more complex than a cube. That said, it's still best to minimize warp by "normalizing" the UV space for polygons, counterwarping the polygons into the UV interstitial spaces.
6. Decal vs. Wallpaper: Some UV layouts present the model as a series of "shells" that each have unique UV space. Contrary to that idea is the wallpaper method, where a texture is designed as a purely tiling bit of art, usable across any of the UV boundaries.
7. Detail vs. Budget: This is especially important if your texture will need to be used by more than one Level of Detail. Low resolution models often have different UV limitations, and the layout will change. Making textures that can be used by varied UV layouts will sacrifice some detail, but will extend usability, lowering processor, footprint and dev budgets.
8. Prerender vs. Pipeline: Even games can benefit from some prerendering, at least when it comes to baking lighting into vertex coloring. Any preprocessing that we can do will aid the game engine.
9. Schedule vs. Polish: Repeatable textures that get used in many different models (with clever cheats to disguise the reuse) means the asset management and art direction are often easier to work with, since things are centralized. (That's the object-oriented model again.)
The Golden Path: There isn't one! The concepts here are just guidelines that will inevitably need adjusting for each project. Even working for a consistent hardware platform doesn't ensure consistency, as the software engine you use may change over time. What I hope to give here is a toolset and principles rather than a blueprint that will inevitably be outmoded.
1. Plan Ahead: Without a fairly clear idea of where you're going to want to wind up, you will waste a lot of time, and will probably wind up wasting vertices, pixels or both.
2. Reduce, Reuse, Recycle: We can and should recycle art assets when working in CG, not only because we can, but because it can reduce development time, asset generation and maintenance, and project data footprint. We should use the idea of "object oriented" texturing where possible.
3. Making the Most of Assets: A consistent philosophy of optimization will often mean the difference between high polish and "good enough", especially if you can squeeze in that last cool visual because your optimization strategy made room for it.
4. Vertex Count vs. Pixel Count and Tileability: Making the most out of assets will often mean finding ways to use the model, texture and vertex color (and maybe normals) together to produce effects that might otherwise be done independently, and more expensively. Tiling textures may get a lot more mileage with careful modeling. Every pixel and vertex needs a reason for existing.
5. Waste vs. Warp: Warping things this way can reduce the waste that comes from UV mapping anything more complex than a cube. That said, it's still best to minimize warp by "normalizing" the UV space for polygons, counterwarping the polygons into the UV interstitial spaces.
6. Decal vs. Wallpaper: Some UV layouts present the model as a series of "shells" that each have unique UV space. Contrary to that idea is the wallpaper method, where a texture is designed as a purely tiling bit of art, usable across any of the UV boundaries.
7. Detail vs. Budget: This is especially important if your texture will need to be used by more than one Level of Detail. Low resolution models often have different UV limitations, and the layout will change. Making textures that can be used by varied UV layouts will sacrifice some detail, but will extend usability, lowering processor, footprint and dev budgets.
8. Prerender vs. Pipeline: Even games can benefit from some prerendering, at least when it comes to baking lighting into vertex coloring. Any preprocessing that we can do will aid the game engine.
9. Schedule vs. Polish: Repeatable textures that get used in many different models (with clever cheats to disguise the reuse) means the asset management and art direction are often easier to work with, since things are centralized. (That's the object-oriented model again.)
The Golden Path: There isn't one! The concepts here are just guidelines that will inevitably need adjusting for each project. Even working for a consistent hardware platform doesn't ensure consistency, as the software engine you use may change over time. What I hope to give here is a toolset and principles rather than a blueprint that will inevitably be outmoded.
Tuesday, February 17, 2009
Web Comic Fun
We've seen a few web comics pop up lately that, in some form or another, pay homage to A Kingdom for Keflings. Here's the first:
This may not mean too much to you unless you've seen this video... It's probably not a direct reference. In fact, the people at Sequential Art may not even know what Keflings are, but we found it pretty funny :)
This comic, however, is a direct reference, and we love it! If you get the other reference (Gelflings!), you're even cooler.
This may not mean too much to you unless you've seen this video... It's probably not a direct reference. In fact, the people at Sequential Art may not even know what Keflings are, but we found it pretty funny :)
This comic, however, is a direct reference, and we love it! If you get the other reference (Gelflings!), you're even cooler.
Tuesday, February 10, 2009
Do Something (How to get hired by a video game company)
DO SOMETHING.
Sometimes I'll be interviewing somebody (let's say, a programmer) who says he wants to make video games more than anything else in his life. So I say "Great! What have you done with that passion? What have you done outside of school, in your spare time? Full game projects? Cool demos? Technology experiments?" And he says "oh, nothing, just my school projects". And I want to CRY!
If you want to be an artist, draw stuff, all the time, starting right now, and work at getting better. Take classes. Go to life-drawing sessions. Learn to draw the human figure. Stop drawing robots and anime characters.
If you want to be a programmer, write code, all the time, starting right now, and work at getting better. Go to school and take game-related classes. Work on some technology experiments and demos. Write a simple game on your own. Get an internship at a game company. Work your way up.
If you want to be a designer, learn to write. Write stuff, all the time, starting right now, and work at getting better. Write designs, write stories, write reviews of other games. Read books about design, and play other games as much as possible, including games that are not normally your cup of tea. Figure out why they're good or bad. Figure out why other people think they're good or bad. Pay attention to popular culture, and figure out what people like. More than anything else, make some games! (pen and paper table-top game, card game, first-person shooter mod, flash game, anything to show an actual product, not just documentation).
Collect all these things you've created into a portfolio, and when you get a chance to interview at a game company, show it to them and say "This is what I want to do!" If they don't hire you, find out why, and fix it.
And if you really want to do this more than anything else, then be willing to work your way up. Get in the door with a smaller job and start proving yourself. That's how I started, and that's how most of the people here got started.
Do something.
Whew.
Monday, February 09, 2009
Animation Class
We held the second of our art education classes last Friday. Brent, our art director, taught us the basics of animation and how to use the 3D Studio Max animation software. The class, which was optional and open to anyone, was attended by about half artists/animators, half other people (2 designers, one programmer and me). First Brent gave us an overview of the 12 basic principles of animation. Those principles come from The Illusion of Life, a book written by two of the artists who learned from and worked with Walt Disney. The book was written for hand animation, but the same rules still apply to computer animation. From the point of view of someone who knew nothing about animation, it was interesting to learn about the different animation rules and how much thought actually goes into drawing cartoons and making games.
Brent then opened up 3D Studio Max and gave us a brief overview of how to use the software. He showed us how to create a basic walk cycle, applying the principles he'd just taught to make an animated walk look normal. The video below is a walk cycle he made before the class as an example:
Overall, it was a very interesting and enlightening class. Thanks Brent!
Brent then opened up 3D Studio Max and gave us a brief overview of how to use the software. He showed us how to create a basic walk cycle, applying the principles he'd just taught to make an animated walk look normal. The video below is a walk cycle he made before the class as an example:
Overall, it was a very interesting and enlightening class. Thanks Brent!
Tuesday, February 03, 2009
Feelin' Lucky?
Well good, because two uber-cool websites are hosting contests giving away NinjaBee stuff right now. The first is hosted by Xbox360Achievements.org and they're giving away a code for each of our old games--Outpost Kaloki X, Cloning Clyde and Band of Bugs. All you have to do is leave a comment in their forums with your gamertag and the number of Keflings you estimate you've kicked. Get more info on the contest here. The contest ends Feb. 7th at midnight, so enter now!
The second contest is hosted by GameStooge.com and they're giving away the above picture, a signed copy of A Kingdom for Keflings concept art. All you have to do to win this is answer the question "If you had a Kingdom, what special laws would you pass?" on their site here. The winner will be picked on Valentine's Day (Feb. 14th) so get your answer in now!
Good luck to all and thanks to our friends at GameStooge and Xbox360Achievements for putting these contests together!
The second contest is hosted by GameStooge.com and they're giving away the above picture, a signed copy of A Kingdom for Keflings concept art. All you have to do to win this is answer the question "If you had a Kingdom, what special laws would you pass?" on their site here. The winner will be picked on Valentine's Day (Feb. 14th) so get your answer in now!
Good luck to all and thanks to our friends at GameStooge and Xbox360Achievements for putting these contests together!
Monday, February 02, 2009
Art Class
In the past, we have held art classes to improve our artists' abilities and let other people in the company learn new skills. We hadn't done any for a while, so last Friday we started it up again with a figure drawing class taught by Jamin, who was our lead artist on A Kingdom for Keflings.
He brought in some materials to serve as a refresher course on the basics of figure drawing. He also showed us how to use a knitting needle to measure proportions.
Here's our lovely model, Shelly....
...and here are some drawings in progress:
He brought in some materials to serve as a refresher course on the basics of figure drawing. He also showed us how to use a knitting needle to measure proportions.
Here's our lovely model, Shelly....
...and here are some drawings in progress:
Friday, January 23, 2009
Contests, Contests, Contests
We like to have fun here at NinjaBee. One way to keep ourselves entertained (besides making games!) is by holding contests. Last January through April or so we held a Cooking Contest. The contestants who signed up were in charge of cooking lunch for the entire company and everyone else got to judge how good it was. We tried some very exotic and very delicious dishes and enjoyed that contest very much. Here's a picture of the first dish we ate, Steve's Saffron Rice Surprise and Brent's Finger-Lickin' Grilled Chicken.
We ate so well those few months that in May we started a weight loss contest...
But I'm getting ahead of myself! In between the Cooking Contest and the Weight Loss contest we had Mustache March. Anybody who wanted to participate grew out a mustache the entire month and sculpted the nastiest mustache they could for the judging day, the last day of March. Most people even dressed up to resemble the character their mustache embodied and then had to get up in front of everyone and explain why they should win. Here are some of our awesome mustachioed employees:
Steve (owner), Mike (designer) and Joey (programmer)
Brent (art director)...or is that Hulk Hogan?
Jacob (artist)-- Check out the necklace.
And the lovely judges who couldn't participate in the contest (and were glad they couldn't!)
Doritos happened to be visiting us a few days before the contest ended, so the second documentary they did here has some great footage of everyone with their mustaches and judging a fake contest.
So after Mustache March and after the Cooking Contest we held a Weight Loss Contest. In 15 weeks our company lost a total of 205 pounds, with our top winner, Joey Kendall, losing a whopping 37 pounds! Go Joey!
Our most recent contest was a Halloween dress up contest. We had some amazing entries, like a Garden Gnome...
...an 80s aerobics instructor...
...and a Plumber...
...but in the end, our winner was a member of The Lollipop Guild!
So we haven't done anything since October and I think we all agree it's time for another contest. Got any good ideas for us?
We ate so well those few months that in May we started a weight loss contest... But I'm getting ahead of myself! In between the Cooking Contest and the Weight Loss contest we had Mustache March. Anybody who wanted to participate grew out a mustache the entire month and sculpted the nastiest mustache they could for the judging day, the last day of March. Most people even dressed up to resemble the character their mustache embodied and then had to get up in front of everyone and explain why they should win. Here are some of our awesome mustachioed employees:
Steve (owner), Mike (designer) and Joey (programmer)
Brent (art director)...or is that Hulk Hogan?
Jacob (artist)-- Check out the necklace.
And the lovely judges who couldn't participate in the contest (and were glad they couldn't!)
Doritos happened to be visiting us a few days before the contest ended, so the second documentary they did here has some great footage of everyone with their mustaches and judging a fake contest.
So after Mustache March and after the Cooking Contest we held a Weight Loss Contest. In 15 weeks our company lost a total of 205 pounds, with our top winner, Joey Kendall, losing a whopping 37 pounds! Go Joey!
Our most recent contest was a Halloween dress up contest. We had some amazing entries, like a Garden Gnome...
...an 80s aerobics instructor...
...and a Plumber...
...but in the end, our winner was a member of The Lollipop Guild!
So we haven't done anything since October and I think we all agree it's time for another contest. Got any good ideas for us?
Subscribe to:
Posts (Atom)