Category Archives: Thoughts

This is an instrument that is used in serious music productions, but funny by itself, makes me laugh out loud.

It’s known as a jaw harp, or Jew’s harp, or juice harp, or mouth harp, or ozark harp, or trump, or guimbarde. Yes, that many (probably more) various names for the instrument.

So how can it be taken seriously with so many names? How can it be taken seriously when it sounds so funny and is played basically by making a “twang-a-lang” sound inside your mouth?

But it makes for a good laugh. Oh, and I’ve personally owned a jaw harp for at least 15-20 years. But I gave up learning because I didn’t know how it was supposed to be played… sheesh.

http://www.dailymotion.com/video/x4qre7_solo-de-guimbarde_music

Here’s some info for developers… Not so useful for a regular app user.  This will be an updated document/post!

There are usually counterparts in competitive things. Blackberry’s OS and iOS and Android, they all have common things that are simply changed a bit, most frequently by name, but maintaining a common set of traits, as I’m going to begin describing. There is much too much documentation on various things to do a comprehensive common comparison, unless I were getting paid to do such an article by someone who wanted it (which I’m open to doing for the right price!). The purpose of constructing this is to give a platform to launch a person into their own research and discovery.

The basic foundational user-interface concepts are what you see, and what you do with it.
The foundational “what you see” element is generally called the “view”. In iOS, this is called UIView and in BlackBerry, it is called Field. For the record, in Google Android, it is called View.
Temporary note: this is comparing BB and iOS, not including Android right now.
What foundational “what you do with it” element is generally a user action. In iOS, the most basic is a UITouch (and derivatives, like UIGestureRecognizer), and in BlackBerry, I think it’s called a trackballClick. Then there are more actions a user can do, like dragging… Sorry if this is too basic, just being well-rounded.

The specific web address for the documentation of each of the view elements are:
http://www.blackberry.com/developers/docs/3.6api/net/rim/device/api/ui/Field.html
http://developer.apple.com/library/ios/#documentation/uikit/reference/UIView_Class/UIView/UIView.html

Manager vs UIViewController
http://www.blackberry.com/developers/docs/3.6api/net/rim/device/api/ui/Manager.html
http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIViewController_Class/Reference/Reference.html

Lots of things going on in life.

I’ve been lethargic/apathetic about a number of important parts of my life, and am really starting to focus.  Helps to rely on good writings by professionals in self-improvement.  Thanks, Brian Tracy!

A large-size whiteboard in my room has a number of papers taped to the perimeter, schedule for the YMCA, a story, a funny editorial cartoon.  Right in the middle, in big coloured letters are the two lines “START DECLARING AFFIRMATIVE STATEMENTS” and “MASTER TIME MANAGEMENT”.

So, that’s what I see when I wake up in the morning… if I look at the white board. hah.

A project that I’m developing, guided by a local real-estate agent, is turning into a minimally profitable venture.  That is good, because most projects I do are not profitable, and I’ve barely survived the last three years (sparing you the story about business partner who don’t pulling their own weight!)

It’s really nice to see projects being useful to other people, and enough so that word of mouth is present, and people start spreading their excitement of their experience with a product or service I have to offer.  Yeah!

Okay this is just a happy post.  I’m crossing my fingers.

Other blog sites probably have content about this subject, but I felt a desire to share my two-cents-worth.

Now I’ve begun to learn Google’s Android OS and it’s helping me appreciate Apple’s iOS more.  Another reason, I found a blog with some good info on it yesterday and had an article something like “10 great things for ____”, and the author created a list of 5 things, and finished the list saying “I’ll get more written soon.”  That was 2 years ago.  Nothing was posted on the blog afterward.  Seems like one of those late-1990’s websites that were PERMANENTLY “under construction”.

So, this is the beginning of a number of writings about the two mobile smartphone operating systems, and I’m writing a bunch of this now, but posting it separately.

Topics:

• Introduction
• Hardware
• OS & Software
• User Interface
• Apps
• … more later, possibly!!

Introduction

Recently, I chose to put effort, serious and dedicated effort, into learning the Android OS for smart phones.  When doing development, it helps very much to have one of the real physical devices to test and give a sense of “yes it works!” excitement, and the money expense also helps force the progress, since a financial commitment has been made.

So I now own an iPod Touch 2^nd generation, iPhone 4, and Acer Liquid E running Android.  These are my mobile development devices, and I am really getting to understand them both more than I could with only the simulators.  Having the iPod touch for two years before the iPhone 4, and having that 2 months before the Android phone, I would think I understand most everything in terms of how it works on iOS, and be irritated when the Android environment is different.  Well, it’s true in most cases, there are a lot of things I prefer about iOS than the Android OS, but the interesting thing is: I realize that I don’t appreciate Apple’s operating system as much without having something different to compare it to.  Thus I am now beginning to understand some philosophy behind the design in iOS, and how it is different to the Android philosophy.

The main difference is the open-versus-closed models; Android being open-source and you can mess around with the OS and recompile it, and install it on the phone, making it do what you want. That’s for the way-out-there developers, but people can install apps anyway in their own home, downloaded from the internet and installed using the Eclipse IDE, if a person is ambitious enough, and patient enough to go through the necessary steps.   The iPhones and iPod Touches can’t have any app downloaded from the internet and installed… they must be downloaded through the device’s App Store app, or through iTunes on the desktop/laptops and synced onto the phone.  Apps are developed in Xcode on  Mac computers, and can only be installed on the device if a person has paid $100 for a yearly subscription to the “iOS Developer Program”.  Then you can download sample apps from the internet, and install them on your device.

Most the other differences are under the hood, which only developers will see or understand.  For example:  Apple expects apps to be singular, and it’s the normal way of apps on a desktop like Microsoft Word or Firefox/Safari/Google Chrome.  You double click an icon for the program,  or a file that is viewed by the program, and the program opens.

With Android, an app can have different bits that are each disconnected from each-other, but are loosely joined together… for example an app that is designed for note taking, allows you to write notes.  But it can also convert notes to PDF files, and you can email those PDF files with the app.  The PDF part is secondary to the note-creation, and yet the app can be made so that any other app can “create a PDF” and this app will be run, but instead of showing the standard note-taking component, ONLY the PDF converter component will be activated.  I haven’t seen this in practical action yet, because I’m only just learning, but this is the way it is according to the introduction on http://developer.android.com.

So those are two examples of philosophy differences, each with a description for Android and iOS.

Next, the more useful information begins.

I am typing this post on my iPod touch, just to let everyone know incase I have spelling errors.

A person suggested the possibility of me writin about the process of developing a game app, or perhaps more about the experience of it than the details.
Well, it is a good idea!
One thing that comes to mind almost immediately is the time consuming tasks.
I find that graphic design takes a lot of time, but it is a very fun process.
Anoter thing that comes to mind is all the late nights up, awake, working on one of the many problems. Like tonight.

Good night!

The central-most Objective-C class in this game I’m developing is called “HBDGame”. The main source file has gone beyond the previously-mentioned 6000 lines and is now over 7200 lines. It seems a lot (for my own records).

Now I want to make a quick post because I will forget if I don’t… and because I do not want to write about this in detail right now.

There is a difficulty in maintaining strong organization when I have over 40 classes and dozens or hundreds of images, giant world map files (around 10/25 made so far) with dozens of configured elements within each, and a handful of soundeffects.

So I have probably 100+ pages of hand-written notes and diagrams and pencil illustrations, plus all the source mockup files for the computer graphics, and e-documents typed to keep myself organized.

And it’s becoming very challenging. I make constant use of text-based two-way references. That’s one of the best helps for me to keep track of execution paths in the program. blah. Now this is really starting to sound technical.. hah.

The major point of this post is simply this: the source-code and information hierarchy model I’ve found myself using (and pretty comfortable with) is something like this:

1. Main game class is HBDGame, and it is the ultimate boss, next to the app delegate itself.
2. There is a layer of persistent data (game settings that are important to keep the same for every game-session, like music volume and choice of accelerometer control versus touch-screen control). This persistent data is saved and loaded by 3 different simple functions.  The HBDGame controls these, and every class that wants stuff saved goes through the boss class.
3. Significant game components, including the GamePlayer, menu systems (main menu, pause menu, quick popup menus) and other significant game objects.
4. Interaction layer which handles the inputs to affect the game.  Some of this goes through the boss, and the boss passes off the inputs to the proper recipient.  Other times it goes directly to the recipient (specifically in the case of menus).
5. Finally, the graphics themselves.  The graphics are controlled almost all completely through the main game components.

Probably doesn’t qualify as a model-view-controller layout.  More like a Global support-storage-model-controller-view.  I think the model-view-controller is a great model for software, but it seems complex projects have blurry lines of communication between the three concepts.

Perhaps there is a better way to organize what I’m doing, but right now I’m still finishing up the core of the game.

I’ll try to write more about this, with concise details, later on.

Here are two reviews of an iPhone app on the Apple App Store, copied mostly word-for-word

Fantastic game 🙂 ***** (5/5 stars rated)
Awesome music soundtrack, great gameplay, just pure love.  I agree that the update should be free, but I still bought the map pack because at least my money goes to the developer who really deserves it.

Pay for new content  *  (1/5 stars rated)
Game is good but having to pay for new maps is ridiculous.  Also saying 5 star rating will keep updates coming.  If I have to pay for updates, what’s the point.

Here I have discovered two immediately accessible cases of opposing attitudes of rating, but similar attitudes about product expectation. Myself, I found the game as a free promotional offer.  I assume it is normally a paid-for app.

I’ll say person A is the 5 star rating, and person B is the 1 star rating.

Person A has a good attitude.  There are a lot of apps out there that are good for fun or for usefulness and should be paid for, or tolerate any advertising that is present in the app to cover some costs of development or maintenance.

Person B expects too much.  What is the point of getting a game if expansions must be paid for?  Sounds like someone who might pay 200 dollars for the Nintendo Wii, or 300-400 for the Sony PS3 but expect 10 games to come with the console, or a full party-pack of controllers instead of the single ones that come packaged.

Maybe lots of people have expectations.  But when they’re very harsh opinions that get tossed into the public domain where anyone can be influenced, the problem that I recognize isn’t the unreasonable harshness or the 1/5 rating despite the first few words being “Game is good”… The real problem is the cultural expectation of what should be free and what should be paid-for.

This is something I’ve been thinking about recently, relating to my own project.

Personally, I think the paid-for content should be anything that is above and beyond the original scope of the project, unless it is an enhancement to the product that actually fits within the original scope.

Now I have been thinking of a number of specific examples of this idea.

When I submit the first release of this product to Apple for approval to the App Store, I am going to make it either free or paid.  My general desire is paid.  This way, NO one tries the app unless it is paid for, and my personal expectation is that only people who really like the app will pay for it because I’m going to have appropriate (but very limited) marketing- good example screen shots of gameplay, not just menus.  Also I plan on marketing a few videos on Youtube.  So it can be known what the game is like and people who want it will buy it, and those who wouldn’t like to pay will just go get something else, for free.  This is my reasoning.  More info follows.

Any app that has better performance developed, say bringing a game from 20 frames-per-second to 30 or 40 fps, is a great development upgrade, and that should be included for free.  It is something that is contained within the original scope because it has no extension to the project.  It is an enhancement of the product but not a true extension/expansion.

Any new artwork that replaces original artwork is also enhancement, but not expansions/extensions.

But any new levels that are adding to gameplay that are not included in the original app are extensions.  It is a good thing for the developer/publisher to have a price set, or make it free if they want.

Another expansion/extension is multiplayer.  This is one of the most significant aspects of a game.  But when is it appropriate to charge for multiplayer?  Seems like it’s always free!

Well, I would say if an app is released as single-player on the app sore, and is FREE, then the multiplayer should be a paid-for extension because the original app is already free for everyone to enjoy.  Adding multiplayer support within a game can be very complicated, and take many hours/days/weeks to setup and polish.  It is in so many games already for free, but most of these games are paid-for and so the consumer may expect multiplayer feature to be free.  I know I would.

So now for any free app, any extension is reasonable to be a paid extension, and even upgrades may be chargable.

The point of a free game is to have a free game.   Can it be any more obvious?  There should be no high expectations.

A paid-for game should have far more content than a free game.  extensions may be free, and some may be paid.  Deciding to make extensions free will be a very welcome thing to anyone who has paid for your app.  Making extensions paid must mean the extensions should be very, very good, sort of like the quality of a whole new app.  Something that adds new vibrancy to the game.

In my case, I am thinking of making large environments in the future, and will try selling them with a custom pricing model (say 1 sub environment for $1, 5 sub environments for $2, 10 sub environments for $5, and so on.

There are many different influencing factors, but one of the biggest influences is whether the app is free on the app store, or paid.

Introduction

Setup

Testing

Conclusions

That’s all, folks!

From Wikipedia’s Freemium page:

Freemium is a business model that works by offering basic Web services, or a basic downloadable digital product, for free, while charging a premium for advanced or special features. The word “freemium” is a portmanteau created by combining the two aspects of the business model: “free” and “premium”.

There are hundreds or thousands of games on the Apple AppStore.  The popularity of it is rising according to numerous reports, and probably it is a very profitable model.  I just heard of the term and so looked it up.  It seemed fairly obvious given the context: a review written for an iPhone game, talking about the free nature and how the extra features are paid (something this particular reviewer did not like).

So, now the question of the moment: should this app I am developing follow the freemium model?  I don’t think I can answer that during the time of this blog post writing, but I will give it some writable thought.

A freemium app gives the public something to try-before-you-buy, but the Apple acceptance for new apps to the AppStore requires all apps to provide a “complete” product, even if it is minimal.

Pros:

• You can get more initial market penetration
• Possibly take advantage of alternate marketing techniques.
• “Free-buyers” may be able to customize their experience of the product in the extensions
• Coming from the previous point, the buyers may find their experience enhanced by a product that can interpret specific combinations of extensions, for example: a car-building game, buying a “racing stripe” paint job and an “air foil” extensions separately may each add individual looks or enhancements to speed, but together they gain a bonus, a synergy from the two.

Cons:

• The product’s “extras” that are premium may not be accepted as “worth the money”, and a greater majority of people may consume the product’s free version, and then carry on with the next shiny thing that catches their eye.
• The “extras” require specific development that extend beyond the core “Free” product scope.  More levels, more characters, etc, cost more time and money to create.
• A buyer may be surprised to find “extras” that he or she, individually, naturally expects as part of the “Free” product, and complain or spread bad reviews complaining about “premiums that ought to be free”
• An update to the free product that requires the previous purchase of a (very) popular extension should only be publicly released after making the popular extension become part of the core free product.  The Apple AppStore’s in-app purchases feature does not permit game logic upgrades, but does permit static data files like artwork (decals) and 3D models (new cars or whatever) and sound.  No new multi-player features, however there are ways around that…  So, realistically, an update to the free product that requires the previous purchase of an extension should not be an update to the free product, rather it should be a paid extension, perhaps one that absorbs and eliminates the previous popular extension

After this analysis, it seems the benefits are all mostly in favour of the end-user, and to a lesser extent, benefiting the company/developer.  The Cons are all weighing more heavily on the company/developer.  There are no major cons to the end-user except for those people who have personal expectations of extra free things, and the free-release of previously paid for products.

I like the idea of the fremium model, and may chose it but for now, the core game must completed.

Today has been a day of guitar-playing, reading, interpreting, typing, mouse-clicking, and dragging.

I built a 3D model of the Bahamas islands plus Turks & Caicos islands. I am using it as the sample of a 3D islands world in my iPhone game project. This is fun! Building in 3D is new to me, but things don’t go in one ear and out the other in this sort of subject. There are SO VERY MANY things to learn in Blender, because it’s not a user-friendly 3D modelling program. I didn’t know that when I started learning it, but now I do know it.

I got into using it from someone’s internet article of 3D and 2D graphic rendering engines for iPhone and iPod touch (and I suppose now, iPad). The person had SIO2 and Oolong as the top two ranked options, but in pros-and-cons, listed Blender as a con for SIO2.

But that’s probably because like me, that person had no experience with 3D art and modelling.  Anyway, I spent the latter half of January going through Blender 3D: Noob to Pro, and have progressed about 40-50% through it.  I should really finish, except SIO2 does not fully support everything, and I’m trying to catch up to the 40-50% full competency of SIO2  before going on with more complex Blender subjects (like animated armatures).

So anyway, going through the tutorials in the source code is what must be done, not reading step-by-step how-to documents.  This is a guerilla-style learning.  Gotta get my feet wet by jumping in 100% and swim with the sharks.  Not that anyone associated with SIO2 is a great white shark, more like very pleasant whale shark… that sounds really odd, but I’m tired now.

When complete, this project will be a lot of fun (I hope!).  A lot of ideas come to me when I’m in a lucid state, so immediately in the morning before I am out of bed and just sort of coming out of unconsiousness, I try to figure out what ideas are lurking.. at the edge of thought.  Collect them up!  They’re worth money in the right hands, my hands!