Tag Archives: game

The experience of writing a game

Posted on June 2, 2010 by Tom

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!

Posted in Activities & Adventures, Technology, Thoughts | Tagged , , | Leave a comment

The organization of a game app

Posted on May 27, 2010 by Tom

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.

Posted in Activities & Adventures, Technology, Thoughts | Tagged , , , , | Leave a comment

Custom rotation/orientation, and almost too much code

Posted on May 14, 2010 by Tom

I have my major iPhone project game-app organized in this manner:

Custom class for appplication delegate class (as all apps have)

it has a generic UIWindow as the view property.

To this window, I add a background wood image.

Then the app delegate creates an instance from a nib, of my main game object view-controller-subclass.  I actually use this view controller subclass as the main model of the game, instead of separating it out to form a more appropriate model-view-controller relationship model.

The game object has a custom UIView subclass, NOT the one for the OpenGL view.

This view is permanently in UIInterfaceOrientationLandscapeRight (the default orientation set in the Info.plist).
Extra trivia: when an orientation change occurs, I manually rotate subviews of the main game view individually.  This is done by  picking one of my five global CGAffineTransform variables created with assigned values

CGAffineTransform transRot0 = CGAffineTransformMakeRotation( 0 );
CGAffineTransform transRotMinus90 = CGAffineTransformMakeRotation( – M_PI / 2 );
CGAffineTransform transRot90 = CGAffineTransformMakeRotation( M_PI / 2 );
CGAffineTransform transRotMinus180 = CGAffineTransformMakeRotation( – M_PI );
CGAffineTransform transRot180 = CGAffineTransformMakeRotation( M_PI );

The two 180s are very important, only if using animations to transition with style.  And that’s what I am doing (in some cases).
The UIInterfaceOrientationLandscapeRight is the same thing as UIDeviceOrientationLandscapeLeft (when you rotate the iPhone or iPod touch from having the home-button down = portrait, to having it on the right-side = device landscape left, the interface must rotate the opposite direction = landscape right, to maintain the same upward direction so you don’t have to tilt your head).  The direction of positive rotation is clockwise,  so if someone starts the app and has the home button down = device/interface portrait, the interface must rotate counter-clockwise 90 degrees, thus I assign transRotMinus90.
NOW IF the device is rotated again to device-landscape-right/interface-landscape-left, all my subviews including the play-screen and main menu will need to be rotated to a 180 degree transform rotation. But because the view was previously a Minus-90 degree, the next rotation should be a Minus-180 degree.  If using animations and assigning all subviews a 180 degree rotation from minus-90 degrees, rotating from portrait to device-landscape-right will have a terrible looking 270 degree opposite rotation.  Again, it isn’t important to do minus-180 if there is no animation.

That’s a long-winded orientation discussion.

And as mentioned, the game-viewcontroller has a custom subclass UIView.  It has two primary views added as subviews (there are other subviews which are not important for discussion).  The first primary view is a view from a custom subclass of UIViewController controlling the main menu, and the second of the two primary views is a custom subclass of UIView which is for the OpenGL graphics.

And I haven’t been working on this today, but I mentioned all of my game’s orientation methods are contained within the main game class, not the custom subview class.

All of this orientation code, and much more (multiple levels of initializing and setup, haha) combine to a pretty large line count – today I went over 6000 lines in this one file.

Everything is very well organized still, so I have no problem navigating or finding things.  Woohoo.  Otherwise, it would be a colossal nightmare.

Posted in Technology | Tagged , , , , , , , , | Leave a comment

What should be paid-for, and what should be free?

Posted on May 7, 2010 by Tom

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.

Posted in Technology, Thoughts | Tagged , , , , | 1 Comment

iPhone app orientation (portrait vs landscape)

Posted on April 20, 2010 by Tom

Introduction

The UIInterfaceOrientation property that can be put in an iPhone app’s Info.plist file, has lead me into a confusing environment of iPhone app orientation design.
At the top level, there are two ways the orientation can be considered: 1- the physical orientation of the device; 2- the orientation of the on-screen user interface.
And when developing an app, these two things can be inconsistent, and confusing.
The iPhone has 7 different physical DEVICE orientations, 3 of which I am not covering (face-up, face-down, unknown).  The 4 device orientations that are considered in this writing are: landscape-left (homebutton is on right), landscape-right (home button is on left), portrait (home button is down), portrait-upside-down (home button is up).
The iPhone has 4 different interface orientations. Two are portrait and portrait-upside-down that equal the physical device portrait orientations.  The other two are the landscape-right and landscape-left, but these are the opposite: interface-landscape-right = device-landscape-left,  and the other is flipped too.  If the device is rotated one way, the interface rotates the other way, to maintain a consistent “up” direction.

Setup

The specifics of my app:
I have a subclassed UIViewController, and its main view property is assigned a subclassed UIView object.
The main view is added to the UIApplication’s window.
Standard setup so far.
The UIView subclass has an overrided – (void) layoutSubviews method.
The UIViewController subclass has a method registered by the app delegate to receive notifications on orientation change, through the default notification centre.

Testing

There is something inconsistent between the notification centre for orientation change, and the value of [UIApplication sharedApplication].statusBarOrientation value.
Now to test:
For a start, the Info.plist file has the UIInterfaceOrientation key set to UIInterfaceOrientationLandscapeRight.
layoutSubviews will always fire first, and a check during the method for [UIApplication sharedApplication].statusBarOrientation shows landscape-right, as defined in the plist.
Then, sometimes-or-not, the orientation-change notification is sent to the registered object.
Starting the app while the device is physically in portrait, NO orientation change notification gets sent.
However, starting while the device is in any other physical orientation, then an orientation change notification is sent.
So it seems there is an expected default physical Portrait orientation, which cannot be manually defined, yet the default interface orientation can be pre-defined using [UIApplication sharedApplication].statusBarOrientation.
There are more haywire behaviours beyond this, if the device is then physically re-oriented after the app starts, more confusing behaviours.

Conclusions

Today was spent working on front-end app menu screens. My project originally started with the style and layout of screens drawn on paper in landscape orientation.  But, before today, I did not know it’s possible to use landscape-orientation images in Interface Builder nib files.  Now I know, and they can be displayed properly, if the right combination of settings are applied, such as the “Simulated User Interface Element-Orientation” setting in the inspector of IB, set to landscape, and interface orientation in the app.
Before today, I’ve done all my customized orientation positioning and rotation using the views’ center, frame, bounds and transform properties.
So, now, I can possibly adopt the built-in auto resize/rotation system.  Even if I don’t use that resize/rotation system, it could also make positioning easier.  It’s not difficult (now), to calculate the horizontal and vertical center of a shape, and position it within another shape whose width and height keeps changing.  Still, an easier way is always a good thing!
Working with all this is leading me to the following conclusions:
  • An app that has some parts that work only in landscape, and other parts that work only in portrait, should be upgraded so all parts work in all orientations.
  • An app that supports either (aka every) orientation, should not have the UIDeviceOrientation key set, because it leads to confusing situations (unless someone can suggest a good reason for it).
  • But, an app that supports any orientation … should, as a standard, start with the Default image designed to be portrait-oriented, not landscape, like so many iPhone games are that I’ve bought.
  • This final concluding point, personally speaking, is the the biggest problem to be solved: the conflicting desires or requirements: the desire to be universal and support either/every orientation (oh the bad memories of the browser wars come flying back), and the desire also prioritize one orientation with the other less-prioritized.

That’s all, folks!

Terrible conflict, but I am happy I could articulate this whole mess!
Posted in Technology, Thoughts | Tagged , , , , , , | Leave a comment

The “freemium” business model.

Posted on March 11, 2010 by Tom

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.

Posted in Technology, Thoughts | Tagged , , , , , , , , , , , | Leave a comment

Progress in movement algorithm design

Posted on February 19, 2010 by Tom

The album Bolero Gypsies: new flamenco is playing in my ears and the book iPhone cool projects from apress is spread open on my lap and I am typing a blog update on the iPod touch.

The chapter in the book I am reading is about the subject of networking. This may be getting ahead of myself, but it’s good to know for when the opportunity presents itself, and it will.

Yesterday, I created the movement of one of the principle game assets that will be moving constantly in the game. Let’s call this object a “bird” (it’s not in the game, neither is it in the air but it serves for this explanation).  The movement requires intelligence, not merely a simple movement like a rotation of some degrees on every game loop (eg. coins in Super Mario games or rings in Sonic the Hedgehog games). The game world may be large when the game is finished. The first draft for movement has become the following: a “home path” in the same style of the common footpath worn by animals in their native environments, when they travel the paths frequently. So it is with this movent. A path throughout any part of the game world.

This path is achieved by using a number of data variables.

The most important is the array of “checkpoints”. These are the same as checkpoints in a racetrack. In my first version of the movement system, the checkpoints are created as cubes in the world 3d model file, with special object names and serial number prefixes, such as “homepath001”. The name is searched and all the points are loaded into an array.

After the array, the most important variable is for storing the index serial number for the checkpoint the bird will be moving toward. Optionally, this destination may be interupted an replaced with any arbitrary location and the bird will move toward there instead.

Now, storing the index value of the next checkpoint allows us to determine the direction of movement whenever we want to. So now, this permits us to consider other random travel destinations.  If any arbitrary destination is chosen at anytime, another variable must store the yes/no status indicating if the object is moving toward the next checkpoint or not. So this possibility brings the necessity of another variable to store the actual destination location instead of only referencing the next checkpoint from the next-checkpoint-index. When the next checkpoint is reached, the index of the next checkpoint is updated, and the location for the new next-checkpoint is copied to this destination as the default destination.

This is just the tip of the iceberg.

Assuming movement toward some arbitrary location is part of the object’s life cycle, not only following a path forever, then it stands to reason to store not only the next destination separate to the next checkpoint as we’ve discussed, but also store the current home-path-location of the bird as soon as a new, arbitrary, destination is created. This will give the bird next-destination options to choose between, when it reaches the arbitrary location.  It may chose to return to it’s home path from where it left the path, somewhat tracing it’s path backward. Or, it may choose to continue to the next checkpoint directly.

In the case of the city pigeon bird, a home path might be the path around a large office building, and its checkpoints are lamp posts and parking lots (it may choose to walk in a parking lot).  When it is anywhere flying or walking, it may decide to go look at something away from its path, but it will try to keep its home building in sight, and if it decides to return, it can go onto wherever it wants, in the direction of its home!

Having more options is always a better thing than few options or only one.

Following this, I have implemented bezier curves for a smooth transition from approaching one checkpoint to the start of the next checkpoint’s path.  It doesn’t work well if a bird (or any other creature) is moving in a straight line and then instantly is moving in a separate direction..

Never before have I worked with bezier curve equations, so it’s brand new.  But I got the equation from Wikipedia’s page and plugged it in, and now it works.  This is a complicated issue, and not really part of algorithm design, but of implementation.

That will remain for some other day.

Posted in Technology | Tagged , , , , , , | Leave a comment

Defining iPhone game app scope

Posted on January 27, 2010 by Tom

I’ve had a bit of annoying troubles today. Not a whole lot, but a bit. I’ve gone through them after a bit of stress.

Classical music does wonders for slowing down and calming my super-fast reading eyes, that my mind can’t keep up with. It also brings a bit of patience. So tasks may be done.

And I didn’t start listening to classical music until around 7:30pm. heh.  Earlier in the day, I built up a document of screen names (eg. load screen, main front screen, instructions screen) and the contents and behaviours on them, from a number of existing iPhone game apps. Using these notes as a starting point for constructing the outer scope of the game. With them, it becomes much easier to see where everything fits from a top-down perspective.

Posted in Technology | Tagged , , , , , , , | Leave a comment

Created a new iPhone app

Posted on January 23, 2010 by Tom

Using iTunes connect, I have setup an app submission. The app is a game whose name is yet to be announced, and is not yet finished. So, the submission will be completed for the review to begin when the game’s design and development are complete.

This is exciting!

Last night or the night before, I installed the iMario app, a free or paid soundboard app. It is too simple, but has a bit of nice images. The sound does not play well, eg. If you press the starman button, the sound plays for several seconds, but if pressing the block smash button, the starman sound cuts out. The playback of any sound is imediately ended if starting a different sound.

Back to the iPhone app: app developers may start the submission process without submitting the product, so I am doing this as an exersize to learn the process now.

Posted in Technology | Tagged , , , , , , | Leave a comment