Archives by Month - December 2009

Home with House ep25 - Reflections 2009

11:35 PM December 31, 2009

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 entry posted by Graham in Home with House episodes  |  Comments (4) Tags: Deep House, Groove House, Progressive House

Unity3D iPhone Development

10:49 PM December 23, 2009

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.

This entry posted by Graham in Velvety Couch Games  |  Comments (3) Tags: Game Development, iPhone, Unity3D

Bank Shot (AKA OddBall) Alpha 01 Videos

10:24 PM December 7, 2009

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 (AKA OddBall). 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.

This entry posted by Graham in OddBalls  |  Comments (1) Tags: Game Development, Youtube Videos

All content © Graham Davis 2021  •  Subscribe