This weekend I realized that I had about 1400 unsorted photos still on my camera from the last 6 months. So I finally decided to go through them and post some here. I have no good excuse for taking so long to post these photos besides just being busy (or more likely lazy). I have some more photos adventures planned for the near future, so there will likely be even more photos to post soon.

While going through these photos I found a lot of moments that I had totally forgotten about. There were a bunch of random photos on there from this and that, including photography class, random outings, photos of sunsets from my balcony, the cat, and various other things. But there was also 3 main "events" that were pretty well catalogued through my camera, and I decided to post those to the website.

One of the events was a trip to Saltspring Island with Asuka for the Ganges Market during the summer. Another was a visit to Davey and Hilary's house with friends. The last was the Victoria Beerfest last September. If you're curious, take a gander at the photos posted in the links below.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

It's a brand new year and a brand new Home with House podcast episode is here. Episode 26 follows in the footsteps of the last few mixes in being deep, progressive and uplifting. There is definitely a dreamlike vibe to this mix with touches of sadness, joy, and contemplation. And this overall tone is fitting for the mix because it will be the last one for a while.

The Home with House podcast is going on hiatus. DJing and music have always been but one of my many hobbies that I use as a creative outlet. I've always found music to be a great way to express myself and it will continue to be so, but every so often you need a break from the usual in order to reflect and come back with new insight, influence, direction and purpose. Right now a lot of my creative energy is being focused in another direction and rather than have the podcast take a back seat and be the result of anything other than 100% of my effort, I'm putting it on the back burner for the time being.

I know some of you will be sadened by this indefinite break from the Home with House podcast, however it is not the end. I know I will return to DJing and music in the not-too-distant future as I know that I won't be able to stay away from it for very long. But for the time being if you have not already done so (or even if you have), I encourage you to go back through the old episodes as there is a lot of great and varied music to be found there. Over 32 hours of unique songs in fact (yes, I just did a quick count). And I'd like to thank everyone who has come to be a fan and who shares the same love and joy for this kind of music as I do. I appreciate all of the comments and feedback from these last few years and I hope you'll be back when I return to mixing again. I've had a great time working on this podcast for the past 26 months and it will be back again in some form or another before you know it. I hope you enjoy this last episode, it's called "Dreamfalling". Peace!

"Dreamfalling" tracklisting:

1. Beach Hoppers - Keep Dreaming (Eskadet Moonlight Version)
2. Manoo & Francois A - Souvenir (Original Mix)
3. George Cochrane - Good Enough (Harold Heath Mix)
4. Mango - Kites (Shingo Nakamura Remix)
5. Damir Pushkar, Fabian Jakopetz - Ocean And Breeze (Original Mix)
6. Kollektiv Turmstrasse - Last Day (Original Mix)
7. Pawas ft. Matthias Keul - Piano Rain (Original Mix)
8. Phil Kinley - Sad Time Space Mix (Original Mix)
9. Monsters At Work - Those Eyes (Original Mix)
10. Ross Couch - Kama Sutra (Original Mix)
11. Mango & Kazusa - Sunahama (Original Mix)
12. Kaskade - 4 AM (Adam K & Soha Mix)
13. Greg Zoi - Loungin' (Original Mix)
14. Glenn Morrison - Contact (Original Mix)
15. Rasmus Faber - Where We Belong (Rafas Epic Reprise)

The last Home with House podcast of the year is here. Similar to last year's final episode, I've gone back through all the podcasts from 2009 and picked at least one track from each mix. I've arranged them into a new mix to reflect back on the Home with House podcast for 2009. This mix is called "Reflections 2009".

"Reflections 2009" tracklisting:

1. Office Gossip - Strangers (Original Mix)
2. Lee Wilson - Life (Tony Loreto & Mario Pagliari Instrumental Mix)
3. Oriental Funk Stew - Sky High (Chuck Love Dub)
4. 4Tune Twins - Feel So Good (Original Mix)
5. Kaskade - Natural (Kaskade Roots Mix)
6. DJ Wady - Mozambu (Johnny Fiasco Mix)
7. Greg Zoi - Loungin' (Short Bus Kids Remix)
8. Ross Couch - Changing Seasons (Original Mix)
9. Kink Army feat. G-Sax - Life Is Saxophony (Original Mix)
10. Gawron Paris - Don't Stop Dis (Earnshaw's Deep String Remix)
11. Grant Nelson - Brave New World (Original Mix)
12. Moony - I Don't Know Why (DJ Chus & Jerome Isma-Ae Superdub Mix)

This is an early alpha screenshot with placeholder graphics - it is not representative of the final game.
While developing my current iPhone game I've encountered many design decisions and limitations that are important to consider for this platform. Some of these are obvious, such as needing to design around the iPhone's weaker memory and graphical power compared to a desktop computer, but others may not be so obvious. Even though my game is not yet finished or released I've already learned some good lessons including how I would do some things differently next time around. I decided to do a quick write-up here about some of the things I've learned so far. If you're interested in developing a game for the iPhone with the Unity3D engine you might find this useful. This write-up is mainly focused on game design considerations including some details of how I dealt with technical limitations.

One of the great things about the powerful Unity3D engine is that you can develop a game and build it for multiple platforms including the PC, Mac, Wii, iPhone and soon the Xbox 360 and more. But just because you can build the same game for all of these platforms doesn't mean it will run well on all of them, and it doesn't mean the gameplay and controls are designed well for each one. This may seem really obvious, but you need to design iPhone games differently from how you might design a PC or console game. First of all, I think the iPhone is best suited for casual games that people can pick up and play for only a few minutes at a time. There are some large scale and deep games for the iPhone, but really the platform shines for its casual games that can be played for 5 minutes while you wait for the bus.

1. Game Controls
Games with simple controls that don't take long to learn are ideal for the iPhone. I've aimed to do this with my Bank Shot game controls, but if I were designing it again from scratch I might reduce the functionality in order to have even less buttons. Because my game provides 4 different powerup abilities, I figured that 4 easy-to-click buttons would be the best way to activate those powerups. However, if I were going back I might design the gameplay so that those powerups are triggered in a different or more automatic way without requiring extra controls and GUI elements. I am a big fan of games that offer simple controls in general, but it is not always easy to provide a lot of functionality without using more complicated controls. Games with more compact gameplay and less functionality will likely require simpler controls that are not only easier to develop, but also easier for players to pick up and play without frustration. Does this mean you shouldn't make large feature-rich iPhone games with complex controls? No, but I think the iPhone is definitely better suited to games that have a very focused gameplay with simple controls that fit the device.

To further illustrate this point, consider that the iPhone doesn't offer you any standard controls that every player can use. There is no keyboard or mouse, and there is no controller. So for instance, a complicated RPG game that gives the player many abilities to use might normally provide keyboard shortcuts on a PC so the user can easily access each ability with 1 click. But with the iPhone you can't do this elegantly if there are too many options. The touch screen and tilt functionality are the developers main tools for building controls on the iPhone. While I'm not a big fan of the tilt-control style games, I do like the freedom of using a touch screen. The problem is that using your fingers on the touch screen takes up valuable screen space that could otherwise show gameplay. You also need to ensure the controls can be used by both large and small fingers and you need to take into account that the player's hands can get in the way of the display as they play. So clearly games with fewer controls are better suited for the iPhone. There is definitely an art to creating new and interesting ways to control games. This can be an interesting challenge that many developers enjoy, but it is not always easy. In my opinion simpler controls are a good goal for any iPhone game. At the very least, designing your control scheme and GUI layout with these considerations in mind should be a top priority when designing your game.

2. Performance Optimizations - Draw Calls
Of course performance is another important consideration when designing an iPhone game. While there have been some pretty graphically impressive 3D games released for the iPhone already, they definitely weren't easy to create. The developers would have been using as many tricks and shortcuts as they could to squeeze as much power out of the iPhone. And while the Unity3D engine does run quite well in 3D on the iPhone, there are definitely some tricks that are necessary for getting better performance. An obvious metric to keep low for better performance is the polygon count of 3D models, but even more important is the number of draw calls. Each object in Unity3D requires at least 1 draw call per frame to display it. Of course, if you are using some shaders or other fancy effects each object could require more than 1 draw call. This means that every button, ball, wall, 2D effect, text box, GUI element or other object that is visible to a game camera will add at least 1 draw call per frame. So it's easy to see how draw calls can stack up quickly. On a modern PC with a decent graphics card, you can have scenes with hundreds of draw calls per frame and have it run very smoothly. But considering that a good target for draw calls on an iPhone 3G is around 15-30 before the framerate starts to suffer badly, you can see why this is one of the main things to optimize for better performance.

Luckily there are a few standard tricks that can help reduce your draw calls while allowing more objects in your scene. In Bank Shot I have around 20 GUI HUD elements on the screen at all times. These include buttons, menu items, text boxes, containers and other 2D graphics. Most of these are dynamic elements that move or that are clickable and so they need to be individual objects in the game. By adapting a script that I got in the Unity3D forums called GUIManager (another great thing about Unity is its large and helpful community of developers) I can combine all of these GUI elements into a single quad object at runtime that requires only a single draw call. The trick is that each GUI element has to share the same material/texture. Using an old trick sometimes called spriting, I've put all of these GUI graphics into a single PNG image and assigned coordinates within that image for each GUI object. By doing this and using the GUIManager script I've turned 20+ draw calls into 1. Unity3D for iPhone also has a new feature that does something similar for 3D objects automatically as long as they share the same material/texture. So by using these tricks and grouping objects together with shared materials/textures you can greatly reduce draw calls.

Another thing to be aware of with draw calls is that using in-game lighting will add another draw call for each light affecting an object. Shining lights on objects makes them seem more 3D and adds more depth to them, but it can easily double the number of draw calls in a scene. So using dynamic in-game lighting on the iPhone is not recommended unless you have very simple game scenes. Luckily there is another trick familiar to developers that was used a lot with older hardware generations called texture baking. In any modern 3D modelling program (which you will be using to make your 3D models before exporting them into Unity3D) you can setup lights that shine on your models. When you've setup all your lights you can then use the texture baking functionality of that modelling program which will "bake" the lighting effect into the texture images of your model. Now you can export your 3D models and use them in Unity3D without any in-game lighting and they will still look shaded with light. The downside to this trick is that the lighting angles are static and can't move or change position in-game, but that's a decent compromise in order to make efficient and better looking 3D games for the iPhone.

3. Performance Optimizations - Gameplay Mechanics
While draw calls are a major focus for iPhone performance, complex code systems can also slow down iPhone framerates quickly. In general you should optimize all code modules and design things in the most efficient ways possible to ensure your game runs adequately. Games with really computational-heavy code can really slow down your game. Things like path-finding, complicated AI, complex procedural systems, or lots of interacting physics objects can eat up CPU cycles fast. So sacrificing functionality and complexity for a smoother gameplay experience are also important things to consider when designing your game. This is not to say you can't have complicated code systems on the iPhone, but it's definitely something to be aware of for performance reasons.

When I was first planning out Bank Shot I considered implementing a messaging system for objects to interact with each other by sending event messages. This is a common way to encapsulate different code systems while allowing game objects to interact easily without knowing about each other. This is a great way to organize code and maintain a large game system, but it is not especially efficient. First of all, you wouldn't use it for messaging events that are very time sensitive. Things like synchronizing states (for instance for network programming) or for polling a game weapon about how much time is left to finish reloading it (which could be milliseconds) are not going to be reliably maintained with messaging. But it is useful for things that aren't extremely time sensitive like telling a game object that the player has died, or in my game I could message a game controller when a ball is scored. If I were making this game only for the PC I would definitely use messaging because it makes things a lot easier code-wise and the resources it uses to broadcast messages to multiple objects is negligible for a powerful system. But on the iPhone messaging uses up valuable resources and can be wasteful. When developing for memory and CPU limited devices like the iPhone you want to be as efficient as possible. So instead of a messaging system I opted for a more direct approach of simply calling functions directly on my game controller. This means that objects need to know more about each other and maintaining the code becomes more complicated. Again, this doesn't mean that you can't use messaging on the iPhone. In fact, the GUIManager I am using in Bank Shot does use messaging to communicate with each GUI element. But this is just a small and confined part of my code, if you are thinking of using messaging for your whole game system you will likely be able to save resources and be more efficient by using alternative methods. In order to squeeze as much performance out of the iPhone it is worth considering such alternatives at the very least.

4. Download Size
Another issue to be aware of for iPhone games is the download size of the full game. Apple forces any App larger than 10Mb to be downloaded through WiFi (or through your computer and later transferred onto your iPhone device). This is not a huge issue, but it could make a difference in the number of people willing to buy and download your game. I personally don't have any detailed statistics proving to what degree this is true, but I have read a few articles suggesting the trend. If your game is below 10Mb in size, people can download it over their phone's cell network from anywhere. If they need a proper WiFi connection that just becomes one more step the person needs to take in order to get your game. It's not hard to see why this can make a difference, but I'm not sure how important it is overall. In the end it is just another issue to be aware of when considering your game design. More complicated or more graphically intensive games will likely be larger in size. If your goal is to make a game that is as approachable as possible to as many people as possible, you will want to keep your game size below 10Mb.

Conclusion
In the end these are not hard rules, they are just observations that I've made during the development of my first iPhone game. Even if you don't agree with some of my suggestions, or if you have a different approach, it is still good to be aware of the issues I've listed and consider them when designing an iPhone game. At the very least it is clear that developers will need to make some compromises and hard design decisions when planning an iPhone game. If you have any suggestions, corrections or other feedback please feel free to leave a comment below.

Note: video footage is from early alpha version with placeholder graphics - not representative of final game
I finally managed to put together a few quick YouTube videos of the current alpha version of Bank Shot. These 3 videos contain a few glances of some of the gameplay features I've been developing for the game so far. The videos go by pretty quickly and may be confusing without a bit of description, so read on for more information.

The first video above shows the use of the moveable cannon shooting the bouncy red ball and trying to score it in the "basket" area. I've actually made some updates to my design and theme lately and the "basket" will soon be changed to a different type of goal, but the idea is still the same (you will eventually be scoring the balls in something else). I will talk more about this in a future blog posting. These videos don't show the mouse cursor (on the iPhone the mouse will really be your finger on a touchscreen anyways) however, dragging the cannon is done with your mouse/finger. The white blocky thing underneath of the cannon is actually a 3D "fire" button that you press and hold to fire the cannon (the longer you hold it, the more power the ball is fired with). Like everything else, this button currently isn't textured so it just looks like a blob of whiteness. This first video mainly just shows a few attempts at scoring the ball (the current "basket" is another white blob near the middle-right of the playing field). This video also gives you a peek at the HUD layout (currently without finalized grpahics) and some of the physics behaviour of the bouncy ball.

The second video below shows the yellow spunge ball in action. This ball floats more and bounces less because of its light spungy material. This video continues in the same vein as the first one but also shows a couple of the ball powerups in action. Since the red ball has already been scored, there are 1000 points that can be spent using powerups. The 4 buttons on the bottom-right of the HUD are the powerup buttons. Currently they are all using placeholder graphics and aren't distinguishable from each other (I just happen to know what order they are in for testing). Eventually they will each display the corresponding powerup graphic and the cost they require to use. Clicking on a powerup button will activate it on the currently active ball. The ball will stay in that powerup mode until you press the same button again to remove it. You will see the "boost" powerup used in this video (again, currently with placeholder graphics for what will eventually be a rotating arrow that helps the user choose what direction to "boost" the ball in). You will also see the "sticky" powerup used (which currently works, but will eventually have "spikes" coming out of the ball to show it sticking to surfaces).

Note: video footage is from early alpha version with placeholder graphics - not representative of final game
The third video below shows the heavy metallic ball in action. This ball falls faster and acts heavier in general. This video shows how 2 balls can be in play at once (although they aren't really interacting much with each other here). The 3 buttons on the bottom-left of the HUD are used for selecting the active ball. Only one ball is active at a time. Whenever you press the "fire" button, whatever ball is currently the active one will instantly become loaded in the cannon and begin firing. So once you've fired a ball into play, you can quickly and easily re-fire it this way. This video also shows the "anvil" powerup in action. This powerup basically turns the ball into a very heavy anvil that falls straight down. It can be useful for scoring when you overshoot the ball (as seen in this video), and will also be useful for breaking certain obstacles/doorways and for holding open interactive buttons in some levels.

Note: video footage is from early alpha version with placeholder graphics - not representative of final game
All 3 of these videos also show the beginnings of the menu system. Each video starts off in the "menu" mode with the large black box that displays the "loading" text. This area will eventually be filled with menu buttons. When you press the "M" button in the top-left of the HUD, the menu closes (or opens if it is already closed) and the black box shrinks (or grows). When the menu shrinks down and the game is in "play" mode, the black box resides at the top-middle of the HUD and will display text messages relevant to the gameplay and story. Yes, there will be a story for this puzzle game. Not the most in-depth story, but a story none-the-less. The game will also pause while you are in menu mode. This is all currently a work-in-progress, but the basic building blocks are now coded and ready to be tweaked as I continue development. While some gameplay and GUI code still needs to be done, most of the work ahead of me is graphics related. So as I continue adding more videos as development of the game progresses, they should start to look prettier. You can view all of the Bank Shot videos here, and all of the Velvety Couch Games videos will eventually be located here. For reference, these are all listed in the Games section of this site.

The last few weeks have been cold and windy, and this month's Home with House podcast reflects that. This mix goes down some of the deeper roads of my house music world. There are hints of jazzy, soulful, atmospheric and progressive house throughout episode 24, but it's definitely on the deeper side. Perfect for a cold Sunday afternoon, this mix will suit your chill mood and hopefully warm you up a bit by the end. Episode 24 is called "Cold Sundays".

"Cold Sundays" tracklisting:

1. Abstract Soul - Inamorata (So Deep) (Original Mix)
2. Dubsativa - Nexus 6 (Original Mix)
3. Stan Kolev - Across Bengal (Original Mix)
4. Paul Hardy, Moodymanc - Sizzler (Original Mix)
5. FreezerRoom - Weapon Of Choice (Fish Go Deep Vocal)
6. Sebastian Davidson - Sunday Morning (Original Mix)
7. Evren Ulusoy - The Night Is Young (Original Mix)
8. Orion & Mango & J Shore - Raining In Osaka (Bale & Voltaire Remix)
9. Ross Couch - Changing Seasons (Original Mix)
10. The Craftsmen - Estrella (Earnshaw's Deep String Remix)
11. Ross Couch - Pure (Original Mix)
12. Shane D feat. Kerry Wood - Silence (McHale & Peddie Mix)

Note: above screen snap is an early alpha version with placeholder graphics - it is not representative of the final game.
With this game development entry I want to describe a bit of my decision process for the gameplay of Bank Shot. As described in this post, Bank Shot is an iPhone physics-based puzzle game where your goal for each level is to score 3 different balls in a basket by firing them out of a cannon. Each of the 3 balls is handled by the physics a bit differently (one ball is bouncy and gets more bounce off walls, another is a sponge ball that is lighter and floats more, and the third ball is a heavy metal ball). The "puzzle" part of each level involves the player figuring out how to get the balls around obstacles by using powerups, skilled shots and strategy. My problem as the game designer is to figure out how to keep this gameplay fun, but also challenging without becoming too frustrating.

My first gameplay iteration had the player using one ball at a time. You needed to pick a ball to use and score it in the basket before moving on to the next ball. But this seemed to fragment the idea of having 3 different ball types: you couldn't interact the different balls with each other or create interesting strategies that combined ball behaviours and powerups. It also made the idea of scoring 3 balls in the same basket a bit more monotonous as you would likely just use the same strategy all 3 times for most levels. So this eventually evolved into the ability to have all 3 balls in play at once. The user still controls one active ball at a time, but you can leave a ball in play doing "something" to help clear the way for the next ball. For instance, the basket might only be easily reachable with the bouncy ball because it needs to bank off a wall and around obstacles nicely into the basket but the other balls can't bounce enough to reach. So perhaps the bouncy ball could first depress a button to open another way to the basket. Once the other balls have scored with this other way the bouncy ball could stop depressing the button and be fired from the cannon again and bounce off the wall to score and complete the level. This idea of the balls "helping" each other and playing off each other opens up a lot more possibilities for both the level design and for how a player might solve each level.

My next gameplay iteration involved the interaction of ball powerups. I've designed 4 powerups that can be applied to each ball by the player. These powerups transform the ball in some form to allow it to interact with the environment differently. For instance, one powerup gives the ball spikes so it can stick to surfaces, and another gives the ball a parachute so that it floats and can be affected by environmental effects such as fans/vents more. But how can I restrict these powerups in a way that doesn't just let the player abuse the powerups to easily complete each level and also so it isn't too restrictive and frustrating for the player? This is even more important when you consider one of the powerups allows the player to pause the active ball and boost it in any direction. If the player could continuously use this ability they could simply boost the balls around all the obstacles without much thought and ruin the puzzles.

At first I had the idea that each level would apply a restricted number of uses to each powerup (for instance I could set the boost powerup to be used only 2 times for a certain level). But this had many problems. Firstly, it would mean that I would have to determine, as the level designer, a good number of uses for each powerup for each specific level. This means I need to think of how I personally want each puzzle to be solved, which not only adds a lot of work to the creation process but also restricts the player by imposing my restrictions on their possible puzzle solutions. It also means that players of different skill levels are forced to solve the puzzle with the skill level I have determined. I want puzzles to have many different solutions and I want to allow the players to feel open to solve each level in their own way. So rather than applying arbitrary restrictions on the use of powerups, I started to think about rewarding the player for using them less instead.

With this method, I decided on using the player's score to manage powerup usage. Every time a powerup is used, it reduces the player's score by a set amount. A player receives a score for each level based on how well they completed that level. So when players complete a level/puzzle by scoring all 3 balls they receive a sense of achievement, but if they complete it with a higher score that sense of achievement should feel greater. With a global leaderboard that I plan to implement, the more hardcore players will want to complete each level with the best score possible in order to compete on the leaderboard. Players that simply want to blast through all the levels easily can use the powerups more freely but will receive lower scores. This will help in restricting the powerups for the more skilled players, but something more still has to be done in order to prevent the more casual players (the ones that don't care much about their score and who only want to beat the level) from just using the powerups non-stop. Again, this should be inherent as part of using the player's score to manage powerups.

By using the simple restriction that a player's score can't go below zero, a player can only use powerups if they have earned some points to spend. Each powerup will require a certain amount of points to use (this will have to be carefully playtested in order to determine which powerups are more powerful and should cost more). So when a player earns points by scoring a basket with another ball, or by reaching a token in a hard to reach part of the level, or by doing something else to raise their score, the player will be able to use powerups more often for that level if they want. Those players concerned about a high score will try to complete the levels with as few powerup uses as possible. More casual players can use the powerups more freely at the cost of a lower ending score for each level, but still within a restricted number of uses. I may also start the player with a certain score on each level in order to allow the use of powerups right away at the start of a level.

So with this score management method I think I have covered all the bases I was concerned about:

• Casual players don't have to think about it too hard and they can use powerups more freely at the cost of lower scores
• More hardcore players will have the added strategy of preserving powerup usage for higher scores
• While there aren't hard set restrictions on the number of powerup uses per level, there is still an inherent way in the system to prevent players from using powerups too much
• I don't have to impose my own solutions on the players for each puzzle, they are more free to solve them however they like
• Players have the added choices of which powerups they want to use and when, for instance they could use 1 boost powerup to score a ball at a certain cost, or perhaps they could use 2 cheaper powerups instead and score for the same or less cost of points

However, even with this solution I realize that gameplay designs can sound good "on paper" but don't always work well when implemented. While I'm optimistic this solution will work well once I have created some more levels to test with, I am still prepared to go back and rethink this design decision if need be. So, if you've suffered through reading this whole entry, what are your thoughts on this design decision? How might you approach the problem differently? Feedback is welcome in the comments below!

Things have been rather busy for me lately, but the waves are finally starting to settle down again. I'm now able to mention that I am starting a new job in two weeks time. I've learned a lot at my current place of employment, but the time has come for me to move on. I'm excited to be starting something new and fresh, and I have high hopes that my new job will help continue my career growth in the right direction.

I've also been spending a fair bit of time on my Bank Shot iPhone game. I have about 90% of the basic gameplay code complete, and I'm just wrapping up a good chunk of the HUD and menu system code now. Tweaking the HUD and GUI has been a bit finicky and time consuming, but soon I will be able to focus more of my time on the actual graphics and level design. Up until now most of the work has been on central code systems to ensure the basic gameplay works and that everything can communicate with each other. My next phase of development includes learning a new 3D modeling program, creating 3D models, skins and animations, designing out some levels and a flow for the game progression, and updating all the little graphical nuances that need attention. So there is still a fair bit of work and a lot of polish to complete before the game is ready to play. But things are moving fairly smoothly now.

I also recognize that I haven't posted a single development video of the game yet. I'm now looking into recording some of the basic systems I have working and posting it here as part of my development diary. Most of the graphics are placeholders so far, but it will be good to share how the game will work and possibly get some feedback. Going too long without any outside feedback can lead to tunnel vision and result in a less balanced game experience. Also, my goal is to start morphing this blog more towards a development diary, at least in part, and so I should really start posting more frequent updates about the specific development I am doing. So you can expect some short videos here soon.

Today is a rather cozy and rainy "inside" day, a good time to post another quick update relating to indie game development. An interesting entry recently posted on the Indie Games Blog is a video from Tig Jam where a bunch of indie developers got together to film quick 5 minute rants. The developers cover a bunch of topics from game development, music, life, the art of making games, why we make games, egos, confidence and everything in between. These very casual talks are quite engaging and informative. So if you have any passing interest in game development and the indie scene, I recommend you check this video out:

• 5 Minute Indie Rants

October's Home with House episode is finally here. This month's mix is a loungy ride suitable for listening to while hanging around the house or perhaps when having a dinner party. It contains equal parts soulful, funky, jazzy, and deep house all while maintaining that lounging vibe. There are moments of relaxed groove, some upbeat and funky sections and a few deeper tracks to keep things interesting.

This mix is a bit unusual for the Home with House podcast series because it has broken away from the 1 or 2 hour mix target. I originally intended to make this a single hour mix but I ran over that time because I was in the flow of the mix. It also happened to fall short of the 2 hour mark because I didn't feel like shoe-horning songs in to stretch it out. So this mix is truly a result of just following the flow. I hope you enjoy episode 23, this one is called "The House that Lounge Built".

"The House that Lounge Built" tracklisting:

1. Roy Davis Jr. - Good Life (Original Mix)
2. Nathan Stewart - Treading Water (Original Mix)
3. Glenn Underground & Daisy Villa - Rize (Main Mix)
4. d-t3ch - Understand The Culture (Original Mix)
5. Anthony Molina feat. Elise Taylor - Perfect Love (James Bledsoe Mix)
6. Greg Zoi - Loungin' (Short Bus Kids Remix)
7. DJN Project - Take You Away (Louie Vega Instrumental)
8. Aaron-Carl - If There Is A Heaven (Soul Deep Vocal Mix)
9. Blaze - Breathe (Liquid People presents Danism Remix)
10. Oscar G & Stryke - Hypnotized (Charles Webster's Chunkster Mix)
11. Ross Couch - Within You Soul (Original Mix)
12. U Lift Me - UPZ (Dubstrumental)
13. Rainy Payne & Sonyae Elise - Houseaholic (Original Mix)
14. Dubgroove - Hit U Off (Original Mix)
15. Pryda - Shadows (Claes Rosen Remix)
16. Heather Johnson - Washes Over Me (Rasmus Faber Epic Vocal Mix)
17. Orion & Mango & J Shore - Raining In Osaka (Original Mix)
18. Martin East Project feat. Jared Douglas - Release (Martin's Deepah Dub)

Continuing on with my recent posts about independent game development, I have another update with some interesting video presentation resources. The Indie Games Blog has recently posted a couple of videos from the 2009 Digital Distribution Summit that happened in Australia last month. The two presentations they posted are on the topic of digital distribution focusing on indie games.

Specifically, these videos discuss how to market and pitch game ideas to digital distribution platforms like Xbox Live Arcade (XBLA), the Playstation Network (PSN), WiiWare for the Wii, and other online platforms for the PC or iPhone, etc. They delve into a lot of topics relating to this which I found very informative. The first video is especially interesting as it was given by the former Worldwide Portfolio Manager for XBLA and contains a good number of examples. So if you are in any way interested in indie game development, or marketing and digital distribution in general, I highly recommend you check out the two videos posted here:

• Weekend Watch: 2009 Digital Distribution Summit