For weeks and weeks, I held to a strict (ever slightly neurotic) discipline. Step towards getting my project done every single day. No exceptions.

I did relax the rule lately. I feel confident that I’m heading towards a happy ending. Meaning, a release. So I’ve been swinging between spare evenings and work evenings, and getting more sleep.

I’m not doing much else except working on content, and marveling at how adding content reveals bugs, and how fixing bugs un-fixes other bugs. But then, I accepted long ago that parts of my engine were poorly written. I would contend it was a sensible move too.

It’s about momentum. I know how to fix my stuff at least. There’s a time to make the code prettier – where prettier means better. Then there’s a time to make the artwork prettier.

I’ve designed technoid environments for parts of the game. But I’m really fond of the outdoor scenes, and I’ve just remastered the wooded areas surrounding Klinnburg.

By the way. There are NPCs in Hairlock. Friends and foes. Just because I’m not showing them doesn’t mean you won’t see them.

I hit a low this weekend, feeling exhausted and dispirited (is that a word?). Finishing a game is exactly what you’d expect. A b**ch to get done with, never mind fixing bugs.

The fact is, the later stages in my game didn’t receive the attention they deserve. Now they do, and that’s good.

I’m putting together a little advice about game graphics. Maybe little use to you if your budget exceeds 10 000$. Otherwise we’re probably on the same boat.

What makes game graphics look rich?

Our perception of game graphics seems largely based on three simple dimensions:

• usability. Graphics are part of a game’s user interface. Poor ergonomics when producing graphics can mean any number of annoyances that can ruin the fun of playing, including, but non limited to:
  • user can’t differentiate walls from the ground
  • user can’t find their way our 3D world
  • user can’t distinguish items from decorations
  • user can’t see gaps between platforms
  • …
• countability. A detail isn’t a detail if it can’t be counted. Twisting a curve this way that way isn’t terribly useful. Adding a couple of spikes on a flat landscape is.
• nameability. Anything that a player can name ‘counts double’. A scene full of details is ‘just full of details’. A village with a horsecar, a well and a church has 4 countable elements. If the well has a roof, you can make it 5. Tiles on the roof? 6.

The bottom line is that being a great artist isn’t necessary, and might in fact work against producing rich game graphics. Graphics for gaming is craft first, art second.

The above rules don’t invalidate whatever we hold to be principles of design. In fact I would rather assume that basic design principles (this blog’s not the place) have been assimilated before considering the above.

Drawing on a piece of paper, I like to express an idea quickly, with as few strokes as I can. But I don’t really think a game scene ever has enough details. Even if you can afford throwing in enough details to crowd a scene, getting everything in (and visually tuning your stuff to avoid the crowded look) is just what you want to do.

What will cost you dearly?

Before I started making graphics for a game, I mostly cared about organic modeling. Fair and square, I concentrated on trying to make human faces. I still don’t think it’s a bad idea and, in fact I would maintain that’s exactly the first thing to worry about. However…

• Making game graphics that interact nicely with a game engine, especially an immature game engine, can be difficult or just frustrating. Making an engine that can support just whatever graphics are brought in can be… …a nightmare. The best approach is to keep it simple (consider squares for a start… don’t underestimate all that can be done with just flat, square terrains).
• Every type of object you might want to model brings it’s own challenges. If you’re new to this, then like me you’ll have something surprising to learn about why natural landscapes are hard to make; why even square buildings with square doors and window frames can be a nag… …and so forth.

What’s not a problem (anymore)

Face and vertex count. I don’t know about textured games. All I know is that the amount of faces and vertices you throw at an iPod touch 8gb isn’t a major issue. Overlaps are an issue. So you can make a smooth, detailed model, but not stack huge faces behind each other. In 2010, even mobile 3D needn’t be rough and blocky.

Save your time and your buck?

Given the above, here are two golden rules that can help producing rich graphics in reasonable time:

*Use simple shapes*
Literally. Use cubes. ball, cylinders, circles. Simple extrusions. It’s not just saving you time; it’s making graphics easier to read for your players.

One argument against simple shapes is that simple shapes don’t amount to anything recognizable. Well they surely do. A plane means nothing. A ball means nothing. A ball above a plane means a whole world, viz. the sun, earth and sky.

*Don’t work against your 3D tool*
As a 3D artist, my 3D tool doesn’t interest me very much. Especially not the features. Every other feature seems to be doing some other stupid thing that doesn’t help creating great models.
As a game creator, I love my 3D tool. Every little feature and function can be used to achieve a slightly different feel. So instead of just using simple shapes, or spending hours fighting with meshes and bezier curves, I can make my graphics more fun and engaging in a few clicks.

While my iPad is waiting to get a programmer’s attention, I ordered a Diga pen to try out drawing software. I doubt whether that’s gonna be much use but… …Just using this thing as a testing device or a reader would be a little limiting, right?

I’m about half-way skinning/refreshing the terrain and completing the plot/puzzles. Feels good.

Moving forward comes at a cost, as I may have hinted at earlier:

• Not considering everything a problem. I watch play-testers doing their thing, try to understand what frustrates the, and that’s not necessarily the growing backlog commenting each stage definition file.
• Getting it right and moving on, or getting it half right and still moving on. Second thoughts have a way to always look better than first ones. Unfortunately if we released after doing everything a second time, it would take twice as long.
• Imagination’s not the limit. My weeny game engine, is. If the engine doesn’t support it, I don’t do it.

I’m wondering if I can release on 3GS first. It would be easier. I spent days and days optimizing, but the game(?) never ends. Otherwise I guess I’ll be in for another week before doing a combined iTouch/iPhone release.

And yea… there’s the slightly oversized iTouch i got the other day. Plenty screen space and hopefully matching horsepower for a future upgrade.

That, and sleeping.

Today I watched Julie and Julia (or vice-versa) and I couldn’t help but get sympathetic to a feel-good movie about the ups, downs and hazards of a wacky personal project. That appropriately reminded me too, that I seemingly never set a hard deadline on my game project. As Brookes quoted:

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you. [The Mythical Man Month p. 13 - originally: Menu of Restaurant Antoine, New Orleans.]

I won’t get into explaining how you cook-up a 12 hours pork stew, or why giving estimates for product delivery is pure technical arrogance facing money-wise operational goals. I’ve been dragging along (not always speed-jetting) carrying a mix of anxiety and anticipation, while clinging to ‘deliver often, deliver early’ as a mantra better than worth repeating every day.

‘Deliver often, deliver early’ could only mean either of two things in my case:

• Make a small product ‘just for the sake of it’.
  I clearly missed several opportunities in this area; in part because I’d done two small prototypes (A flash-card thing for chinese and a nicely animated icon matching game) and couldn’t see how this could either make money or, more importantly, drive the development of something more ambitious); in part because instead of starting making/learning/porting a 3D engine (a concrete, pragmatic move towards making a game), I wrote an (optional) behavior scripting system that merely implied the many components needed in a finished product.
• Define a ‘minimally marketable’ design for my product, and stick to it.
  On this side I’ve been more constant. While there’s a couple of non essential features that won’t make their way into the first release, I clearly anticipated early on what I needed to make my game usable, and keep it ‘minimally fun’.

Unsurprisingly, I didn’t start getting any good feedback from my casual play testers until I managed to tick all the boxes off ‘minimally playable and fun’. And now I do. I hear that my game is… …playable and fun.

OK, I lied. What it feels more like is, I’ve been working on this huge pile of cool stuff, until the day I patched it all together, only to realize it was neither playable, nor fun. I could have released a fun, playable game maybe 3 months ago. What’s true, however, is that that game wouldn’t have been as good as my prototype is now, because most of the cool stuff is making its way into the final product.

For the record, here’s a few things that aren’t needed to make a fun, playable 3D game, but still nice to have. In other words, the things that you might leave out if you need to release and make money ASAP:

• Support for exporting animations (you could make a space shooter instead, or whatever…).
• Procedural grass.
• Lighting (ever played Katamari on your iTouch?)
• Behavior scripting
• Cool camera management
• Modeling (or procedurally generating) natural landscapes
• …

‘By the way, maybe you should check what seems like an interesting article temptatively rooting Agile into Brookes’ book.

One more thing. Coding is nothing like cooking. Cooking may take 6 hours. Cooking may take a day. But cooking’s just cooking. Coding up stuff takes ages.

Plus, cooking is a healthy activity where you get to stand, scurry and scour the local markets for fresh veg, meat and fish. My back is half-killing me.

I’ve been trying to wrap up gameplay and interaction programming this week-end. Let’s see what else I still need to take care of

• Animation. that was meant to be finishing a couple of weeks ago; feels like I never really started. <<Sigh>>
• More landscaping.  Putting the old stuff back and getting new stuff in.
• Game design related – dialogues and a couple key actions that somehow got left out.
• Sound

I’d rather start and finish with the landscaping before I go back to my design issues and animations. Ideally if that could take two days it would be great… I doubt. Let’s check the situation:

1. I need to fix the grass/decoration modules. That’s essential.
2. In exchange of getting the above to work nicely, I should agree to keep the rest minimally simple. And in the same pass, I should bring my design closer to console style graphics; more fun and less romance. Minimally simple means that time is better spent adding a very stylized windmill (or whatever else) than working on having beautifully chunks of terrain. For all I know I might just have little cushion shape slabs, or the like. Use simple, childish shapes.
   The goal of this is to make things look more playful and less strict. But also…
   …graphics should support and encourage using an easy, brisk animation style. Think about design and symbols, not art and animation.

What’s up with my grass then?

I have intermittent rendering bugs when drawing my grass. This didn’t happen before I updated the terrain. Right now I don’t see the bugs anymore. Here’s what I know:

• Parts of the terrain become transparent, showing the non-GL background behind.
• Both color and coordinates seem garbled.
• Changing a so called overlap parameter in my procedural grass parameter seems to affect the result.
• Along with this, a specific overlap parameter (0.28) sometimes causes the game to freeze for quite a while (about 2 minutes).
• This looks like passing junk memory to the GL

Here’s a couple of random things I want to try:

• remove a glBindBuffer statement in my RawMeshRenderer. I don’t need these for now. But I doubt this will make a difference.
• Check for malloc() failed. I’m not sure what malloc() should return when it fails (zero? or should the program just crash?)

I’m left guessing. Compared to my previous terrain I pass many small terrain units, with just a few polygons. And my previous terrain never showed this bug. I already put a guard against allocating zero when there are no blades of grass (in theory this situation would never occur anyway, even though my terrain chunks are much smaller.

But right now I can’t reproduce the bug.

Adapting decorations

One simple bug I’m encountering with decorations is that, since most terrain chunks are now quite small, the number of decorations per terrain tends to average under 0.5, meaning no decorations are displayed. Easily fixed with a random cast.

After spending 3 evenings trying to fix my camera management, I was a little disappointed to discover that my camera positioning rules still conflict, causing inelegant jumps in places.

Guess i’ll just have to simplify a little for now. I need to get my fighting system working. Nothing really complex yet. Here’s where I stand:

• I introduced per frame character bounds for collision detection. OK, say we have a character jumping forward or extending a kick. The character’s location vector doesn’t change. What changes is how the character occupies space. With per frame character bounds, we’re not getting really specific, but we avoid unacceptable approximations.
• I arrange the PC to orient themselves towards a potential target (and disable hitting when there’s no NPC around). I’m doing this because we’re projecting space on a 2D screen and using an on-screen joypad. I feel it would be difficult for most players to aim at a target efficiently, and it’s not quite the point of my game.

Meanwhile, this stuff doesn’t really resolve how fighting should work in my game… let’s take a few examples to clarify.

RPG style fighting

There are many slightly different ways RPGs resolve fighting. I’ll be ignoring turn based games as this is a bit far off for me. Here’s an idealization of how this works:

• PC can engage combat or escape.
• When fighting, PC cannot avoid hits (NPC can miss, but that’s related to stats)
• NPC cannot avoid hits
• Timing is not important.
• PC can use potions during combat
• Minimally, PC needs to engage combat. In some games you can die because NPCs engage you, but you don’t engage them. In realtime fighting RPGs, the player must push a button for every hit.
• Typically, PC wins because their stats are better.
• PC needs to rest after fighting in order to recover health points. This is somewhat of a late addition, but it’s getting quite popular. Depending on the game, HPs are slowly increasing all the time, or potions only can restore HP, or the PC needs to be still, or the PC needs to sleep at an inn.

In RPG style fighting, the intensity of the fight is linked with three parameters:

• Experience. Two well matched opponents makes for a more ‘interesting’ match.
• Exhaustion. Even minor NPCs can outmatch a bold PC that went too quick, too far. In other words if an area has many NPCs, the PC doesn’t have time to recover and fighting becomes more risky.
• Chance. Most RPGs include an element of chance (esp. critical hits) making fighting more interesting, because even a lower level PC or NPC can get lucky and win an otherwise losing match.

Action style fighting (no shooting)

My understanding of that is even fuzzier; roughly speaking, there seems to be three dimensions to consider:

• Reflexes. The fastest opponent tends to win the fight. Games that rely more on this also rely on the player getting faster over time, as they get more used to the controls. This dimension is likely biased towards the player in many games, because the PC is faster to execute moves than NPCs
• Range. Often the player’s range is wider than NPCs. This allows a careful player to neutralize opponents before they are in range.
• Moves. In fighting games, the outcome of a contest seems to be determined on a case basis, depending on moves executed simultaneously/near simultaneously by both opponents. Example: A does a high kick, B does a low kick => B wins. A does a high kick, B does a punch => B loses.

What’s ‘light action’ like?

This is what I want to try in a first approximation:

• If the PC doesn’t have a weapon good enough, the weapon is, strictly, ineffective.
• If the PC is hitting the NPC, only the NPC loses points (and, likely, dies in one stroke)
• If the NPC is hitting the PC, but the PC isn’t hitting them, the PC loses a point.
• The PC has 3 points.
• The PC can recover their points after a cooling period.

To be continued?

Today I’ve carried out a telling experiment while creating my first half-decent kick animation (ever):

• The three step animation recipe doesn’t seem to work so well for a player action – at least it doesn’t feel right. Let’s not throw gold into a well. What I think is happening is that, when hitting a button, a player’s physical action includes preparation and impulse, so the expected behavior (at least for arcade style animation) is to complete the action. At least my animation looks better this way – after I’ve cut the first half, keeping no anticipation and  starting right in the middle of the action phase.
• My engine has been running to its limit, making balancing pointless in most cases. I’ve noticed that because I tested my animation in Blender first, and it felt smooth at 15FPS, but felt jumpy on the phone even though it was meant to balance around 15. This brings two interesting notes:
  • Around 9-11 FPS, a game needn’t feel jumpy on a small screen, or I would have noticed earlier. Surely 15 to 30 look increasingly smooth, but balancing graphics against FPS is a genuine alternative. Even though I choose 15 as a reference, a colleague more used to targeting 60FPS on desktop platforms shrugged it off, pointing out that camera motion didn’t feel jumpy. However…
  • For my kick animation (and likely other action oriented play) getting my work to look good requires 15 to 20 FPS, and I’d much rather balance at around 18.

This doesn’t tell the whole story. To a fair extent its a matter of style. I also remember an animation teacher pointing out that ‘unlike 2D, 3D action dies out as soon as motion stops’. Extrapolating a little, I’d say that, the more an object looks real, the more it requires smooth, convincingly realistic animation. Bit of a worry for me because my technology and craft are kind of half baked, with the modeling side miles ahead the animation.

Graze not, or not just yet…

Right. I removed my pretty grass for now, I know I can chunk it and display much less at once (and I will) but for now several factors point towards simplification:

• I’m worried about the cost of artwork. This may not be fair because I did spend a lot of time writing modules for my engine while getting on with the artwork.
• I’m losing illusions regarding game-space. I don’t like game space to be too simple and square, but there are ergonomics and gameplay issues involved. If the terrain is simple and easy to understand, players will tackle the terrain. If the player is complex, some players will head on while others would really rather just ‘point and touch’ and expect an invisible copilot to path-find where they want to go.
• If I need to balance around 17FPS, something else has to go, at least until I optimize a little more.
• I feel the need to focus on gameplay versus art. If you remember the boxed product game era, you will probably recall how pretty a game box typically looked compared to the actual product. Well we can think of it as a lie factor, or (generously) as a transposition. While players surely don’t play the box, having fun with the game didn’t necessarily involve high end graphics. Anyway, I feel the revival/long death of 16 bit style gaming may somehow associate simple graphics with cool gameplay.

Enough ramblings. what I really mean is, I probably need to shift the balance a little – less artwork, more gameplay and more speed. But for now…

I’m fixing a couple of frame stepping related bugs.

Note: looking back at my posts, I’m not sure if it’s fair to incriminate artwork when trying to analyze how long this thing is taking. Clearly I’ve been working mostly on the engine and UI for the past 2 weeks or so. Building the engine takes time. If the engine is reused, that’s an investment, otherwise, call it pure waste.
More coding ahoy, see below :)

Working notes for combat

I’m having a go at checking in more detail if I can get a little action to really happen in my game, and I’m not too happy. Here’s the general idea:

• Characters have actions
• Some actions can affect other characters.
• Actions are ranged in various ways (maybe too many ways)
• Actions can be narrowed using an angle. If the opponent is not facing the target within this angle, no result occurs.

I dunno – I maybe tired or I may be getting lazy. I’m trying this out with rats jumping at the PC, and I see bugs, but I also wonder, why do I really need to define all this stuff? Wouldn’t it be tons easier to refine my boundary testing a little?

Yeah… I guess. And likely much less error prone. Here is what I would  consider:

1. Bounds need to be evaluated per frame, and take orientation into account.
2. Bounds can be spherical. Likely that’s faster and easier.
3. Evaluating bounds using materials can be very useful. This way we can avoid larger than life approximations when simulating, say, sword fight.
4. Speed is a simple element to consider. Speed is more significant than impact frames. Let’s take a quick example. The rats jump one meter ahead and the impact frame is 25. At around 20 frames per second, that’s a little slower than one meter per second, giving us (for something I can relate to) 3.6 km / hour. That matches pretty well with my original idea: a rat isn’t a projectile, it jumps to bite (I dare hope real rats don’t jump neck high).
   The kick animation is much faster,  covering 1.5 meter in just 3 frames. That makes 6 x 1.5 = 9 meters per second, more like 30 km/hour. Unsurprisingly that’s about the speed limit in villages in France. Granted it’s possible to get really hurt at that speed, the more likely compromise there is that you can see a car coming at that speed, not at 120. A foot is a decent projectile.

It’s not about simulating, more about making life easier – not just defining impact frames takes time (open blender, scroll through animations, copy parameters…) it also makes stuff inherently fragile.

Like copying object coordinates instead of loading them; but that’s another story.

I feel I’ve been struggling with camera and navigation management for the whole week.

So much so that there won’t be anything technical about this post. Navigation management is meant to avoid players getting too easily blocked by walls and other obstacles. Camera management means to ensure the PC is always visible.

I’m just about getting away with it. The more hopeful side of things is, all the complications I’m dealing with go along with a terrain that seems too complex for adventure game players to be bothered with. Most adventure games have an emphasis on pretty graphics; they’re also games in which (a) the computer path-finds your way or (b) getting about is no thrill, so you can actually enjoy the scenery and the story.

I really wish I could say that simplicity is the key – and it is, but then again, it depends which end of the rope you’re burning from. I like cool artwork. I have a baroque spirit for ups and downs, bridges, ladders and so forth. So I guess I’ll need to scale it down.

Not all game designers will start from this end. And not all players like trivial, casual games. As a player, I tend to use my iTouch as a reasonably powerful, very pocket-able console. I don’t have hours to play, but I’ve still the soul of a gamer in my finest hour.

And I find the store a little bit boring at times.

I’m setting up a basic system for focusing the camera when a NPC is nearby the player. OK, that’s not great photography, but I need to start somewhere. Right?

• If there is no NPC nearby, the player is the target.
• If there is a NPC nearby, the target is halfway between the player and the NPC, and the camera distance is adjusted to something like K x d, where K is a constant, and d is the distance between the player and that NPC.

OK, it’s not like there’s no camera management already. Need to get this stuff working together:

1. The camera position is controlled by the accelerometer, but not the distance to the target
2. At the moment the distance to the target is controlled by whatever moves the avatar. That’s because if the avatar is walking towards the screen, I want to look from further so the player can see what they’re walking towards. Rudimentary, but kind of works.

I’m just trying to get away with it. In fact i’m starting to be seriously annoyed with the code structure. I’d need a kind of pipeline to put all this stuff together, but for now I’ll just muddle through.

At least I wrote a separate photo manager class to implement the targeting policy. To avoid yet another singleton, i’ll bind that to… …SpeedControllerUsingAccelerometer, a class I originally wrote to do what it says, except right now that’s controlling the avatar by randomly endorsing a compass widget somewhere else. Grmphfff…

There you go. I forgot my camera distance update was stupidly linked to the player operating the compass/joypad. Fine. Good opportunity to upgrade my photo manager to a well formed action and move the camera distance management code to the photo manager as well. Neat.

Anyhow, I use K = 2.5, that ensures my avatar and the NPC are showing (we’re targeting a point halfway, so we need to be careful with that) and some padding on a 35mm camera or so (something standard). The only thing I’d like is be able to anticipate a little – have the camera head towards a new target before it’s actually possible to show that target. That’s a little more tricky, and here’s why:

• I focus on a target when it’s within 5 meters from the avatar. In this case, the distance needs to be 12.5 meters.
• Beyond 14 meters or so, we’re really surveying the scene from too far.

The tricky part would/will be to figure where the target point should be located (for example, how close to the avatar versus the target) granted the avatar should always be showing onscreen.

Caveat

My camera management used to be much simpler; for one thing, the camera eye/target used to lie on a line parallel to the z axis. With the accelerometer and the photo management breaking that rule, i’m starting to see quite a few artifacts (stuff getting clamped because the renderer believes it won’t be showing on-screen

Raw…

…genius? That’s what it felt like when I finally got it working. Even though getting stuff in closeup doesn’t always compliment the quality of modeling, this really brings life to my little prototype – and because I’ve been planning on doing this for a long time, there’s a feeling of validation that I wish I could feel more often.

So I immediately extended this to props, which can either be picked or introduce narrative elements – now there’s a proof baking my pudding. It’s a little bit too much of a lead for stuff that can be picked, but feels perfect for a medium promoting casual entertainment.

After…

• A super-long week-end (just 3 days really)
• Adding an app icon (57×57 png, add to your project, then list in your something-Info.plist file)
• Adding help, pause, a splash screen and a loading screen
• …

I got a few friends to try my game. I was actually deluding myself into believing this thing is playable. Well just about. Most of my friends are non players and non iPhone users. Realtime 3D or whatever I put into it to make my game exciting, attractive, and worth giving a go, means nothing to them – gotta remember they’ve just seen Avatar in an IMax cinema, right?

Usability

After Doodle Jump’s super-massive international success, I like to kid myself into believing that every iPhone gamer can tilt their phone (also a good way to keep your screen clean). Before I get back to my fairy world, maybe I should list some of the many usability issues that seem to plague my game.

1. Tilt. My tilt navigation isn’t super sensitive, and it’s pretty easy to stop moving also. Since there had to be a way to go pick the phone while stirring your veggies, in other words get your both hands free, I only use touch for action buttons and pausing the game.
   I love it, and would contend this is ideal for an adventure game with light action, but I’m really worried after seeing how quickly this gets the non-initiated frustrated with my baby app. I’m currently considering drawing a pad on the screen. Now that’s gonna bore me to bits.
   It’s not just because I don’t want to get into GL picking this round. Many games seem to provide touch and a joypad emulator, and some testers seem to favor the latter.
2. Not seeing their character. That’s the downside of having a fairly complex game stage and automating camera management. Making sure the camera is always well placed isn’t so easy, and i’m still working on it.
3. Getting blocked. I’ve more or less given up on having the PC fall down cliffs in my game. Everywhere is cliffy and it’s not meant to be Super Monkey Ball. My trial users like to run into walls, and feel stuck.
4. Getting kinda stuck. Because my terrain is a little complex, I already put a lot of work into avoiding getting the PC completely stuck between rocks or other things. I half believe having easier controls is more than half of the problem – I see my mock players getting stuck in places they really didn’t intend to go… but…
5. Talkback management. When my game pauses, I display a little on-screen explanation showing how to play the game. This starts with the Avatar talking to you and it’s really cute. Problem is, when touching the screen again, the talkback doesn’t disappear right away. So I had a friend pressing again, which pauses the game again, doesn’t make the talkback disappear (that one’s got a timer) either. Then they press again. And again. And again…
6. Where are the buttons. I don’t really want buttons to cover half of my 3D view. I made them reasonably sized (fingertip sized?) and translucent. Maybe a little too translucent…

The one true player that really enjoyed my game so far is an 18 months old. Pity demographic transitions and the baby crash.

Gameplay

Right. All that stuff makes me feel a little sad after the groove of feeling ready to show off stuff. Good news is, my next target is putting together preview pics.