Permalink | Leave a comment  »

It's been a long week, but I'm happy to say that all of the 26  missions  (we may add a few more) for the core campaign in little soldiers have been roughed out and all of the world map nodes have levels attached to them. Now begins the daunting work of  playtesting and making sure our difficulty curve is accessible to new players and that we introduce new concepts at the right pace to keep players engaged.

A big thanks to Z for all his help on the levels :)  "With testers like these, who needs game designers?"

Permalink | Leave a comment  »

As we march towards the beta (code complete + final assets) build of Little Soldiers HD, I've had to start wrapping my head around what makes Little Soldiers HD compelling and differentiates it from other games.  Here's an initial pass at what I think will make Little Soldiers stand out.

1. Intuitive touch interface designed for the iPhone
2. High definition 3D graphics
3. Not your moms physics puzzler, Little Soldiers HD is...
   • ...action oriented with a smart camera that follows the action and explosive chain reactions.
   • ...character based, lead your team of soldiers to complete missions by escaping levels
   • ...rewarding, earn medals and unlock levels & vehicles as you progress though the campaign.

I think games that are designed from the ground up to have a iPhone friendly touch interface have a competitive advantage over ones that aren't. You wont find any virtual d-pads or virtual joysticks in little soldiers. The menus, the settings pages, the level map, and the gameplay were all designed to work intuitively and naturally with touch input. In some cases a lot of time and iterations were spent to make this as fluid as possible.

The game does have polished 3D graphics (or will have when we hit beta). This takes more effort and production time then the 2D graphics that a lot of 3 month development time iPhone games have. I believe that 2D can look better then 3D in many ways, but there is also an impression of quality and professionalism that you experience with 3D graphics that is sometimes hard to duplicate with standard 2D graphics. Still with incredibly high quality 3D graphics like the ones that are seen in the Gameloft games, I wonder if the bar is set so high for 3D that it may not be possible for games like LS to create that experience for players.

The rest of the description focuses on what differentiates Little Soldiers HD from your standard Rube Goldberg style physics puzzler. Having real characters instead of an abstract object like a ball or cube invites players to be more engaged in the game. The same is true of the object interactions which are more explosive and volatile then a lot of physics puzzlers that feel more like a science experiment.

Permalink | Leave a comment  »

...especially in logic or puzzle games.  I generally don't criticize games publicly. Games are difficult to make just from a technical standpoint, once you factor in user experience, games design and that elusive quality of "fun" they're nearly impossible to make. The games I do sometimes criticize, or rather the developers I like to criticize are the ones that circumvent this arduous creative process and chose to copy the design, aesthetics, and "fun" of another game verbatim. Today I'm going to point that criticism at one of my own games and by association at myself.

There is a tendency amongst designers when designing puzzle games to make levels more challenging by making them larger and more complex. The original little soldiers is no exception to this classic design flaw.

This is a screenshot of the "Jam Packed" level from the original Little Soldiers game.  It's full of repeating elements, you can't even see the exit goal and it's not clear what you are supposed to be doing in the level. Essentially to play this level, you must try different things, failing repeatedly until something randomly seems to work at which point you hop though the exit and breath a sigh of relief.

I'm not your typical puzzle gamer, but I'm pretty sure you'd have to be masochistic to consider this success though repeated failure as "fun". I've since realized that the "fun" in a puzzle game of this sort is in learning the rules about how items behave and how they interact. Once the player has figured out the "trick" to an item it really isn't enjoyable to use that item over and over again on increasingly large levels, unless of course every time they use the item they learn something new about it's behavior.

In short the challenge or fun in the game is in learning about the objects, once they are mastered there's very little satisfaction in repeatedly applying them in larger and larger problems. A smaller level that teaches the player something new, is more enjoyable then a large level that has the player applying skills they've already mastered repeatedly. This sort of thing is intuitive in retrospect, but I've seen this same level design issue crop up in a lot of  physics based  or item based puzzle games.  

What do you think? what makes a logic/puzzle game fun?

Permalink | Leave a comment  »

It's hard to imagine that on Oct 20th (a month and 10 days ago) the game looked like this.

and now It's starting to look a lot more finished. It's amazing how art can make a game "sing" :)

There are still lots of little details I would love to add, but I'm not sure we'll get the time. When you earn a medal for your performance on a level, i want to have it added to the folder in a rewarding way, with a sound and some particles or something like that. It would be nice to tweak the layout of the information on the folder to make it more attractive, but we'll see. Some things inevitably get pushed off to a future update after the games released. Hopefully by the end of the week, we'll be able to do a similar before and after shot for the in game levels and see how far those have come in what is really a very short amount of time. It's encouraging to remind ourselves of all the progress we've made as we march slowly toward releasing the game working on little tweaks and forgotten features and feeling like progress is slowing down.

Permalink | Leave a comment  »

For the last couple of months, Chris (the creative guy :)) has been steadily cranking out massive amounts of content: textures, sprites, models, backdrops, buttons, overlays, etc. And with each passing day, our memory footprint grows and grows. To the point where last weekend Alex wasn't able to test anything because we were crashing within seconds of the app starting up on the iPhone. Now, to set the record straight, we did all the 'good practices' of building textures and sprites for a 2D/3D game. We load the textures into 16-bit buffers of the best pixel format for the image. We atlas all our 2D content to fit as many images onto a single texture as possible: (like this soldier atlas, which is 1024x1024 in it's final state).

So how do we solve these memory problems? First off, how much texture data is the game using at run time, and is it feasible? We took a look at all our content and counted up the size of all the images the game could be using at any given time, and with 16-bit textures, it should sit around 10-11 megs of memory on the iPhone.. Which is just barely within the 'safe-zone' for older 3G iPhones... (approximately 13 megs).

Next, we added some memory counting code for textures and Alex loaded up the Apple iPhone profiling tools to check out our memory footprint at run time to see what was going on. At peek load times.. we were hitting upwards of 40 Megs!! which is way out of the safe zone for iPhone apps.. Now with our estimated max of 11 megs.. and maybe another 1 meg for various buffers and such, why are we hitting 40 megs?!

The short answer: Image loading and conversion.. The long of it: What does it really take to get a PNG file loaded into a 16-bit texture. And the answer is, given that you must use Apples built in png loader, you load the 32-bit image, convert it to a 16-bit image, then uploads the texture to memory.. At run time... :( Way too many operations, way too much work, and way too much memory for what really needs to be done.

So, we moved all this work and memory usage to the build process by writing a custom step in our asset tool chain, that takes texture images, converts them to the destination pixel format, and saves them to a custom file format using simple ZLib zip compression. At load time, we simply allocate a texture, and use the fast Zlib library to decompress chunks of the file & upload them to the texture. In the end, our load time is about 3x faster and we peak at 14 megs of memory in load times.. back in the safe zone.  And most importantly, we haven't seen an iPhone crash in days :D

Permalink | Leave a comment  »

Our alpha (feature complete) milestone was supposed to be yesterday. We've spilled a little over into today, but managed to do some really cool stuff that wasn't supposed to be part of alpha.  One of the cool new add's is when you beat the bootcamp levels and move out into the larger map you are awarded a truck for your efforts. It's a really nice reward for the player after working though the first few levels.  This is what it looks like...

This is also a first pass on the level popup to show medals based on performance. Chris (the artist) hasn't really had a chance to see it yet. You can see the truck in there as well. It's not the only mode of transportation you can earn playing LS HD, the other(s) you will have to play to discover :)

Permalink | Leave a comment  »

It sounds a bit pretentious to talk about rules for doing something. I hope that these rules aren't coming across as preachy, these are literally the rules I tell myself to follow now when i'm implementing  a touch interface. They are handy tools because most of them are unintuitive, at least coming from the perspective I was with regard to touch interfaces. One of my misconceptions was that touch, or direct manipulation was awesome because you could actually manipulate things directly like you could in the real world, providing a whole new level of accessibility not previously found on mobile devices.

This turned out to be  partially true. It's true that directly manipulating physical objects like switches and toggles are a uniquely accessible interface paradigm, but it's also true that a touch interface is nothing like directly manipulating a switch or an object. This leads to rule no. 2.

2. Rarely do you want to use touch input data directly. By this I mean, rarely do you want to take the x,y coordinate of a touch and reposition anything based on it's exact location. In the real world when you toggle a switch or drag a piece of paper across your desk, nothing move unless directly acted on by your finger. On the iPhone things are a little trickier. Take the On / Off toggle I recently implemented for the settings menu.

If by chance a quick touch had enough input to move the slider, it would toggle so fast the user wouldn't get to enjoy the transition between the On and OFF state. I might as well have used two images, one in the on state and one in the off and switched between them.  The resulting solution involved a surprising amount of subtly, using the momentum of the touch and intelligently auto completing the toggle from On to Off or visa versa based on the direction and velocity of the touch input the control received. The other part was to ensure the toggle never moved faster then a certain maximum speed to make sure that the user always got to experience a nice analog transition from on to off to really achieve that accessible interface feel.

Another great example is in scrolling your games window via touch. If you just try to position the screen under the users finger, it feels wrong. To be rapidly moving the screen and then have it instantly stop when the finger is released. This is how you'd like to handle the case as a programmer. Touch starts... begin scrolling the game window... touch moves... keep scrolling... touch ends... stop scrolling. This ends up feeling choppy and slightly frustrating to use, what is really needed is to take the velocity that the finger was traveling and apply a diminishing fraction of that velocity to the screen after the touch is released. That way the user feels like they have imparted some momentum to the scrolling like they would if they were flicking a piece of paper across a tabletop. It's unintuitive for a programmer to code this way, but once you wrap your head around it you can create some pretty slick feeling and easy to use interfaces.

Permalink | Leave a comment  »

It's been quite interesting implemented a touch based user interface for Little Soldiers HD. There is definitely a lot to learn and not all of it is entirely intuitive at first. One of my goals for the interface in LS HD is to make sure it feels at home and natural on the iphone, this means leaving behind a lot of the paradigms that exist for mouse based interfaces. When I started working on the menu screens for LS I had only one datapoint. Something that I herd in an apple keynote somewhere,  with touch you can directly manipulate objects so you don't need to control them by clicking on little boxes. The example they used was the On / Off switch you see all over the iPhone settings screens. Instead of a checkbox that you tapped to toggle  [  ] to [X] , they had this nice analog switch that you could manipulate directly by touching it. I loved the intuative nature of "sliding a switch" to toggle something on or off and I wanted all our interfaces to behave that way.

It turns out, everything is not easy as it seems, and it does take some work to get things to respond as naturally as they do in the iPhone UI kit. The largest unwritten law that I've discovered is that while "direct manipulation via touch" is nice, it's not sufficient.

Rule #1 : Your UI object should always be manipulatable by a singe tap of the finger. Direct manipulation of controls is great, but is difficult for most new users to discover.  I have 3 examples here that are made better by having single tap manipulation. The first place I ran into this rule was the in game menu.

Initially I had this great scheme where someone would drag the touch over the menu button, and then the menu would pop up, the user would drag up over the option they wanted and then when they released the touch over that option it would perform the action.  It made great intuitive sense to me, Begin a touch over the menu button, the menu stays visible for the duration of the touch, ending the touch hides the menu or makes a selection from the menu.  It totally failed the wife test.

Out for dinner at a steakhouse for date night, I had her try the game. I watched in horror as she tapped away at the menu button, the menu flickering on for the brief interval her finger was on the screen. "Whats wrong with the menu she asked?".  "Touch and hold" I said, depressed knowing a good user experience is one that's discoverable. The touch and hold code still exsists, but that night I went back and changed the behavior code so that tapping the menu button makes the menu pop up, and then tapping a menu options makes a selection while tapping outside the menu hides it.

The nice thing is that both behaviors, touch-and-hold, and tap can coexist. This makes the interface work the way the user wants it to work, which is an attribute of good UI design. The next place I saw it was on the On/Off toggle.

The interesting thing about making elements in the interface "tap" accessible was suddenly the ones that weren't were really annoying. The last example was the folder popup that shows in "title" form until the user dragged it up to reveal the play button and level achievements (not yet implemented). Being forced to drag this folder up with a swipe started to feel like a real chore so it was a no brainier to make it hide or show itself if it was tapped.

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

One thing all testers know but few talk about in open audience is the downtime we can experience on a regular basis. testing apps and games alike is great, minus the potential downtime from major refactors and rewrites. Not so much of a big deal on larger products as there always seems to be something to occupy your time. Documentation, test plans, usability flows, etc.. but on smaller projects (ie little soldiers HD) there just isn’t that much “busy work” to do when your team is in the midst of major changes.

What do I do when justin is writing the game physics or dan is fiddling with how sprites are drawn on the level map? I’m glad you asked! Sometimes I find bits of code or logic I don’t like, play around with them and see if I can present a better solution. Sometimes I write blog posts and Sometimes I just read through the code to see if I can identify potential weak points for test. Make myself mental notes (or real ones if I’ve had enough coffee) of where I see that code might fall apart in use and test it later after a stable build is posted. At the very least reading through the code puts me in the mindset of the dev that wrote it and lets me see the product through their eyes (important for me when I’m trying to figure out where their logic might fall short). In a lot of scenarios when I find a bug, if I have time, I’ll browse through the source to try and identify where it is before I log it. Sometimes it takes the developer a little while to reproduce the bug, set up the debugger, track down the error, grab the call stack, get to the root of the problem and Identify the actual bug. All that time that they’re not thinking of how implement their new feature or how to get their physics to apply in scenario A but not B, etc.. Not to mention changing mindsets is always a pain, switching focus from one problem to the next just isn’t an instant process (a fact I wish more PM’s and sales people realized).

A good example is when this project started, development was being done mostly on PCs and a small amount on OSX. After I got ramped up on the project and deployed out to the iphone there seemed to be a DB problem with the persistence of saved data. Since the developers are busy enough I took it on myself to try and figure out why the data wasn’t persisting. My first thoughts were the SQL statements themselves or specifically, the finalize portion of the statement, weren’t being sent correctly. After reading through the code I realized the DB wasn’t being copied out of the bundle. At that point I hit up the closest dev to confirm my suspicion and have it fixed asap.. The problem never presented to anybody else because on the PC or OSX the data is modified just fine but the iphone OS doesn’t allow modifications to the DB while its in the bundle (safety feature, I’ guess).

Anyway, I’d write more but Dan just made a checkin and imma go test some stuff =D

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »

Permalink | Leave a comment  »