NinjaBee Dance

iPhone Developer NinjaBee Announces it has Finished Making Love

2009-07-16T09:54:00.000-07:00

OREM, Utah – July 13, 2009 – NinjaBee, makers of Kaloki Adventure for the iPhone™ and iPod^®touch, announced today it has finished making Kaloki Love, the next installment in the Kaloki series. Kaloki Love brings new characters, a new story and new scenarios to the space station building series. The game is available on the App Store (http://linktoapp.com/kaloki+love) for US $0.99.

"Right after finishing up Kaloki Adventure, we started work on Kaloki Love,” said Steve Taylor, president of NinjaBee. “Making Love was fun, but a lot of work - a lot of give and take, you know? Making sure everyone was satisfied took a lot of stamina, but in the end the whole team was happy."

Kaloki Love is a new way to build a space station. Players will fill the boots of a dashing new "hero" as they meet four potential sweethearts and woo the dream girl of their choice in this romantic five-part story. Multiple endings based on how the game is played means the player can always experience new romances or fix failed ones. The game also includes five bonus scenarios with goals and new strategies.

Features of the iPhone/iPod touch game include:

Five Levels of space station management and falling in love
Five bonus scenarios which feature fireworks, asteroids, Greek gods and more!
A distinctive art style and a catchy soundtrack
Auto Save: progress is automatically saved in the event of a disturbance
Easy-to-learn, friendly and fun for the whole family.

The original game, Kaloki Adventure, is available on the App Store for US $2.99 (http://linktoapp.com/kaloki+adventure) and a taste of the game, Kaloki Free, can be downloaded for free (http://linktoapp.com/kaloki+free). One additional story in the Kaloki universe, Kaloki War, will be released at a later date. For more information about Kaloki Love for iPhone and iPod touch, please visit http://www.NinjaBee.com/ikalokilove/

About NinjaBee

NinjaBee, located in Orem, Utah, began developing games in 2004. With every game they make, NinjaBee’s goal is to create a unique, top-quality, fun experience for people of all ages. Their popular titles include Outpost Kaloki X, Cloning Clyde, Band of Bugs, Boingz, Doritos Dash of Destruction and A Kingdom for Keflings.

For more information, please contact the numbers above or visit http://www.NinjaBee.com.

Wahoo Studios and NinjaBee are registered trademarks of Wahoo Studios, Inc. All other company names mentioned herein may be trademarks of their respective owners. Copyright © 2009 Wahoo Studios, Inc., All Rights Reserved.

Apple, the Apple logo, iPod, and iTunes are trademarks of Apple Inc., registered in the U.S. and other countries. iPhone is a trademark of Apple Inc.

###

Come Play with Us!

2009-07-08T07:54:00.001-07:00

To celebrate the release of the Band of Bugs Avatar update and the Tales of Kaloki DLC, NinjaBee will be hosting a Game with Developer night this Saturday, July 11 on Xbox LIVE from 7-10 p.m. EST. Our gamertags are listed below. If you want to play with any of us, just send a friend request and we'll be on that night to play and answer your burning questions, or just chat. See you there!

* gostay (Steve, President)
* YaZeus (Kevin, Lead Programmer)
* Big Blue Fox (Brent, Art Director)
* dajuse (Justin, Project Manager)
* T G Welfman (Eric, Programmer)
* Marmosetofdeath (Jeremy, Lead Designer)
* johnseph83 (John, Programmer)
* DarkMount (Jeff, Artist)
* scarabman (Ben, Designer)
* Abbasax (Jason, Test Lead)
* ThePr0tege (Mike, Tester)
* NinjaGirl01 (Valerie, PR/Marketing)

iPhone Developer Spotlight

2009-07-07T12:07:00.000-07:00

Congrats to our lead developer, Kevin Heap, who was spotlighted on AppCraver.com for his work on Kaloki Adventure. Here's a snippet of the question-and-answer segment, but you can read the whole thing here.

When did you start developing apps for the iPhone? Did you have previous experience as a developer?

We started working on the iPhone in October 2008. Wahoo Studios has been around since 2001 and in 2004 we created the NinjaBee brand to showcase our independent, self-published games. We released Outpost Kaloki X in November 2005 with the launch of the Xbox 360 on Xbox LIVE Arcade. So we’ve got lots of experience making video games, but this is our first for the iPhone.

What / how many apps have you made so far?

We have 2 apps out right now - Kaloki Adventure and Kaloki Free. We’ve also got two more apps on the way; Kaloki Love and Kaloki War.

What type of apps/games/software inspires you? Where do you get your ideas?

I’m inspired by games that make you think - which usually means simulation/strategy games - but I’m a sucker for a compelling story with just about any genre of games. There have been so many games that have inspired me since I was a kid, but the game that really inspired me to want to *make* video games was the original King’s Quest game.

Band of Bugs Music

2009-07-02T14:41:00.000-07:00

Because we're in a giving mood here at NinjaBee (and we're super excited for the release of the Avatar update next week!), here are the music tracks from Band of Bugs. 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. All tracks were done by our very own designer/Music Man Extraordinaire, Mike Neilsen.

Hopper's Groove
Insectus Maximus
Many-Legged Mayhem
Jungle Pygmy Bugs

Band of Bugs gets Avatar support and all-new DLC

2009-06-30T08:18:00.000-07:00

NinjaBee Lets Avatars be the Hero, Releases New Game as DLC

OREM, Utah – June 29, 2009 – NinjaBee, the creators of the first fully-enabled Avatar game on Xbox LIVE® Arcade, A Kingdom for Keflings, announced today that beginning July 8, Band of Bugs will include Avatar support. In addition, NinjaBee will be releasing Tales of Kaloki, a new, game-changing DLC for Band of Bugs.

The added Avatar support will allow gamers the option of replacing the original story’s hero, Maal, with their custom Avatar as they play through the main story mode. Players will also be able to engage in hand-to-hand combat and spell casting in eight-player Spider Hunter mode. Spider Hunter, one of several multiplayer modes, allows players to battle with or against their friends over Xbox LIVE to survive an onslaught of deadly spiders, mosquitoes, centipedes and more.

The Tales of Kaloki DLC is based on NinjaBee’s first Xbox LIVE Arcade game, Outpost Kaloki X. The DLC is set in space and uses the basic mechanics of Band of Bugs but adds a new tile set, new characters, new story, new skills, new strategy, new attacks and new abilities.

“We’re giving you an entirely new game,” said Steve Taylor, president of NinjaBee. “The Tales of Kaloki DLC is Band of Bugs but with long-range combat using lasers, rocket launchers, OO rays and a ton of other sweet weapons to blow attacking space ships to smithereens. It’s all the wackiness from Outpost Kaloki X and tactics from Band of Bugs rolled into one, and we’re stoked to be releasing it.”

In addition, NinjaBee will release a Band of Bugs Premium Theme. This theme, which features scenes from the game and concept art, can be downloaded through the Xbox LIVE Marketplace for 240 Microsoft Points.

The Avatar support will be added to the original game for free and the Tales of Kaloki DLC will be purchasable through the Xbox LIVE Marketplace for 240 Microsoft Points. Like the extensive collection of DLC already available for Band of Bugs, Tales of Kaloki can be played by downloading the original game, Band of Bugs (800 MS points). The Avatar support, Tales of Kaloki DLC and the Premium Theme will be available Wednesday, July 8. Band of Bugs is rated E for Everyone.

About NinjaBee
NinjaBee, located in Orem, Utah, began developing games in 2004. With every game they make, NinjaBee’s goal is to create a unique, top-quality, fun experience for people of all ages. Their popular titles include Outpost Kaloki X, Cloning Clyde, Band of Bugs, Boingz, Doritos Dash of Destruction and A Kingdom for Keflings.

For more information, please visit http://www.NinjaBee.com.

Wahoo Studios and NinjaBee are registered trademarks of Wahoo Studios, Inc. All other company names mentioned herein may be trademarks of their respective owners. Copyright © 2009 Wahoo Studios, Inc., All Rights Reserved.

###

Avatars and Fireballs

2009-06-23T12:19:00.000-07:00

So we released this picture today announcing that we're bringing new things to Avatars that you haven't been able to do previously, like throw fireballs with your Avatar.

To clear up any confusion, this image was taken from a screenshot from the game. Our art director, Brent, took it from the screenshot and erased the background, touched up the color, tilted the positioning so the Avatar was in a better position and added a glow around the Avatar, but other than that, nothing was added in terms of the fireball. You will, in fact, be able to throw a fireball in this game. And a whole bunch of other really cool stuff.

Later in the week we'll be posting more info on this new prospect, so follow this blog, follow us on Twitter, or check out our forums for more info!

Indie Game Developer: The Definition

2009-06-15T23:10:00.000-07:00

A continual debate rages that is more charged than politics, more heartfelt than religious conviction and more hotly contested than Roe vs. Wade. The unanswered question echoes; “What is Indie game development?” This argument endures throughout the year, but it’s never heard louder than right after the announcement of finalists or winners of an Indie game development contest. Cries of “Cheater, Cheater, you’re not I N D I E” ring throughout the air (well, okay, the internet air).

My desire to unite the world and promote love and happiness has driven my quest for an answer. Not just an answer to satisfy myself but one that is so clear and so undeniable that everyone must agree, “That’s Indie.” I believe that, in a moment of pure brilliance, I have uncovered the truth.

Drum roll…..

Indie is exactly what you are. Anyone who you think has an advantage over you isn’t Indie.

I was fortunate enough to spend a couple of years living in Italy. There I learned something about human nature. Many of the northern Italians believe that their culture and traditions are different from the southern Italians. They also believe that they are slightly superior to their southern neighbors. The northern Italians are quick to point out the higher crime rate in southern Italy and the fact the Italian Mob also began there. I believe this type of division is common in many countries, cities and even small towns. The fact that this division exists isn’t interesting in itself. The interesting observation is the geographical location where everyone places this division between the north and the south. I lived in many different cities during my stay in Italy and I noticed that everyone placed the division just a little south of where they lived. The further north a person lived the higher he or she felt that dividing line should be. In fact, in some very northern cities many of the Italians consider themselves to be Swiss. They were just stuck in Italy because of some arbitrary division of countries and would quickly point out that their ancestors, living in that very city many generations ago, hadn’t always been Italian. Despite the fact everyone in these towns can speak perfect Italian, many would choose to not speak Italian and often pretend they didn’t know how.

This same type of thinking is often apparent when developers are finding reasons to disqualify a developer from holding the honored title of “Indie.” This list can be as innumerable of the stars. It is rare that a definition is solely based on what qualifies a developer, but instead focuses on what limitations a developer must embrace. Some of these restrictions include items such as the following:

• Big publisher financial support
• Budgets that are too big
• Financing from investors
• Too much industry experience
• Publishing on platforms other than PC or Mac (no consoles)
• Publishing on any platform or with any web site that has restrictions or requirements
• Having worked with publishers - ever
• Previous Indie development success
• Schedules that are considered too long for the development of a single game
• Too large of a team
• Use of office space for development instead of a basement
• Use of commercial software or big commercial game engines
• Telling a story in a game
• Visuals that are too high-end and pretty
• Use of 3D
• Making a game that is mainstream and commercially viable (No first-person shooters)
• Desire for financial success
• Lack of distain for authority and publishers
• Not high enough quality

Of course this is just a small sampling of disqualifiers. The amounts on some of these items also can vary greatly. For example, on the budget issue, some developers go so far as to say that you shouldn’t spend any actual money--everything should be done with free, volunteered labor--while others might place the budget cap at $1 million.

Some of these restrictions seem very logical and fair and some seem totally ridiculous. But look closely. Can you see how each item actually reveals the self perceived flaw or weakness of the developer who is using these criteria as a means of disqualification of other developers? For example, the developer who excludes developers who use too large of a team may actually wish he had a bigger team or at lest think he could make a better game with a bigger team. Take thought before you next choose to cry out in protest--you may be inadvertently exposing your innermost insecurities to the world.

There are some developers who feel confident enough to include other developers with larger teams and lots more cash than themselves in the sacred Indie circle. These individuals simply believe that these factors don’t actually provide as strong of an advantage as other attributes often found in Indie developers. With creative freedom and a willingness to take risks, they can make amazing games that aren’t dependant on big teams or big budgets.

This definition doesn’t answer the question of who should be granted the privilege of entering an Indie game development contest. However, it forces me to think harder about my own evaluation of who I consider to be an Indie developer. The next time I try and make this distinction, I should ask myself the question, “Would my opinion change if I was just like them?”

Outpost Kaloki Music

2009-05-13T16:53:00.001-07:00

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

Indie Game Night

2009-05-05T09:34:00.000-07:00

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.

iPhone Lessons

2009-04-27T09:03:00.000-07:00

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.

NinjaBee games now on Amazon!

2009-04-09T11:10:00.000-07:00

(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?

April Fool's!

2009-04-01T12:01:00.000-07:00

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 :)

A Kingdom for Keflings Music

2009-03-27T10:50:00.000-07:00

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!

Thank You!!!

2009-03-24T15:05:00.000-07:00

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!!

Fan Pic and Contest Result

2009-03-19T15:30:00.000-07:00

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.

Normal Mapping and 3D Modeling Programs

2009-03-11T10:20:00.000-07:00

[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.

Random, Fun, Interesting Links

2009-03-10T12:10:00.000-07:00

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.

Vote for A Kingdom for Keflings!

2009-03-03T09:44:00.000-08:00

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]

Testing, Testing...

2009-03-02T16:52:00.000-08:00

[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

Intro to 3D Studio Max Class

2009-02-27T13:23:00.000-08:00

[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.

Texture Optimization Class

2009-02-25T09:38:00.000-08:00

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.

Web Comic Fun

2009-02-17T10:00:00.000-08:00

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.

Do Something (How to get hired by a video game company)

2009-02-10T09:47:00.000-08:00

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.

Animation Class

2009-02-09T15:09:00.000-08:00

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!

Feelin' Lucky?

2009-02-03T10:39:00.000-08:00

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!