Interfaces design

The interfaces of our game in Objective-C

 
/**
 * Interface: ImageLoader
 * Usage: Load UIImage necessary in the game
 *
 */
 
@interface ImageLoader : NSObject
{
	UIImage *backgroundImage;
	NSArray *monsterImages;
}
 
@property (readonly, nonatomic, retain) UIImage *backgroundImage;
 
- (id) initWithAllImagesLoaded;
- (id) getMonsterImages: (int) monsterNumber withStatus: (int) status;
 
@end
 
 
/**
 * Interface: Monster
 * Usage: A instance of this class represent a monster in the game. This class inherits UIImageView class.
 *
 */
 
@interface Monster : UIImageView  {
	int type;
	int madCounter;
	int locationX;
	int locationY;
	NSArray *adjacentMonsters; // optional
}
 
@property (atomic, assign) int type;
@property (atomic, assign) int madCounter;
@property (atomic, assign) int locationX;
@property (atomic, assign) int locationY;
 
- (id) initWithUIImage: (UIImage *) image andTheGame: (TheGame *) game;
- (Monster *) getAdjacentMonsterInDirection: (int) direction;
- (void) setAdjacentMonster: (Monster *) monster inDirection: (int) direction
- (bool) shiftAlongDirection: (int) direction andDistance: (int) distance;
- (void) performMovingAnimationAlongDirection: (int) direction andDistance: (int) distance;
- (void) performMatchAnimationStartAtMonster: (Monster *) monster andDirection: (int) direction;
- (bool) checkMatches;
 
@end
 
/**
 * Interface: Board
 * Usage: A instance of this class is responsible to maintain a 2D array that store all the monsters in the game.
 *
 */
 
@interface Board : NSObject {
	NSArray allMonsters;
}
 
- (id) initWithTheGame: (TheGame *)  game;
- (Monster *) getMonsterWithLocationX: (int) x AndLocationY: (int) y;
- (void) setMonster: (Monster *) monster withLocationX: (int) x andLocationY: (int) y;
- (void) removeMonsterWithLocationX: (int) x andLocationY: (int) y;
- (Bool) shiftRowNumber: (int) number alongDirection: (int) directon;
- (Bool) shiftColumnNumber: (int) number alongDirection: (int) directon;
- (void) clear;
 
@end
 
/**
 * Interface: TheGame
 * Usage: A instance of this class comprise essential object of the game.
 *
 */
 
@interface TheGame: NSObject {
	ImageLoader *imageLoader;
	Board *board;
	int numberOfMatches;
	int penaltyCounter;
}
 
@property (nonatomic, retain) ImageLoader *imageLoader;
@property (nonatomic, retain) Board *board;
@property (nonatomic, assign) int numberOfMatches;
@property (nonatomic, assign) int penaltyCounter;
 
- (void) createLevel;
 
@end

Visual presentation on IPhone

In the fourth week, we manage to writing code and see the exact look of our game. However, the result is not the same as our expectation.

- The colors change a little bit, and are darker than the image shown last time.
- The background and the monsters are blurred a little bit, and this significatently reduce the quality of our game graphics.

We both believe that it is mainly because Mac and Windows use slightly different standard to display colors. We will try to adjust the images so as to fit into the Mac platform.

Simple demo

In the project description, we briefly describe the how to play our mini game. Here, we would like to show it in pictures.

The above picture shows nine tiny monsters group around and form a large square. The aim of player is to lead at least three tiny monsters group horizontally or vertically. However, player is only allowed to move the monster in the following way.

Picking up a tiny monster only from the edges. The following picture shows that the monster at location [0, 1] is picked. The red arrows indicate the location with direction where the picked monster can be “pushed” back.

Let's push the tiny monster to location showed in the picture below.

The entire horizontal line is pushed to the left so that the empty squares is filled. All the monsters in this horizontal line is shifted one square to the left.

The blue monsters on the left hand side form a line, and we say that player obtains a match.

Story behind Monster Manager

Monster Manager is the mini game that we are going to make. We borrow the idea of another mini game called “Zoo Keeper”. In the game, player act as a manager who works in a large monster manufactory on an island, and is responsible to take care of the production process in creating monsters. One day, the machines that create monsters are suddenly out of order, and many monsters continually come out from the machines and there is no way to stop those machines immediately. Player, as the manager of the manufactory, is responsible to handle the chaos.

Unfortunately, this is not an easy task because all monsters always like living with their compatriots and are afraid of being alone. They will do any unimaginable things if they are being alone for a long time. Therefore, players should try the best to group the monsters with the same type together and wait until someone switches off the machines.

Mini Game VS Public Transport Information System

After the meeting with Prof. king, we gradually feel that making such a Information System requires lots of awesome features, and gathers those features together. Although there are many new ideas coming out from our mind, they are not easy to be implemented properly. Also, too much features making us cannot concentrate on just a few features and put them into our information system. Moreover, although even some of the ideas sound interest, however they are just not quite useful.

On the other hand, We think that a mini game seems to be more suitable to us, as a good game in fact does not requires to have complex design and nice graphics, but a good information system should.

Therefore, we change to make a mini game that is already designed before.

What a coincidence?

After settling down our topic, we briefly planned our schedule and started reading documentations. However, right after the Mid-Autumn festival, David discovered that a local iphone app. [Minibus 2.1(selling us$9.99 at ITunes)] is going to release a new version [Minibus 3.0] with GPS support in December. Which means, there will be a commercial product with similar features as our conceptual design and possibly their new version are faster than our app. to be released. Are we going to compete with them? And how?

Maybe we can focus on another particular public transport,say the MTR, and not to touch their area(buses).

Besides, David stated something very important. We have to seek permission from the transport company before using their information. And most importantly, the permission seeking time can take long. What if they don't allow us to use? Anyway, we have to ask them first. I'll send the request in these few days.

Several problems to be dealt with and time is running. Let's speed up!

Why Public Transport Database

In Hong Kong, public transport is essential to everyone. For me, when going to some unfamiliar places, I have no ideas where I can find the particular bus stop. That's why a public transport database in our mobile I think is helpful. In my conception: After the GPS in Iphone locating one's location, the user chooses his destination and our program with a map displayed would tell the user where(the nearest station) to take the public transport to the destination.

Final decision

In the second week, we have proposed quite a lot of ideas since the time we design to change our project to IPhone application. We thought of developing games, painting program and database related program. The following is a list of ideas we thought of…

• 2D Pool
• 3D Pool

• Sand drawing
• Strategy board game
• Mini games
• Public transport database related software

At the beginning, we started to think about the Pool game, as I have some experiences on writing a 3D pool game. However, we abandoned this idea very soon as we found out that both 2D and 3D pool games were already created by someone and were avaiable on iTunes Store. At the same time, I proposed a sand drawing painting program and strategy board game. We both think that Sand drawing is interesting, and it can make use of mult-touch feature perfectly. However, building such a program is easy, but how to make it awesome is then a difficult task. On the other hand, strategy board game is popular nowadays. Quoridor, QUARTO! are two famous board game published by a French company called Gigamic. We soon realized that those board should have copyright and therefore we though for other idea again. Finally, Richard proposed a public transport database related software and I proposed a mini game. Richard thought his idea is better, and I thought my idea is better. We argued the matter over a day, and we finally design to accept Richard's idea.

We agree on the point that there are already lots of games on the iTune Store. Nearly half of the top paid applications on the iTune Store are game. Also, professor King want us to make application that is local. So, it seems that public transport database related software is better that mini game. However, I will still manage to make my mini game in my leisure time. :)

Changing topic

After a long discussion and deep thought, We determine to inform Professor King that we would like to change our topic from teletable to IPhone application. It is a important decision as the topic we selected finally can completely affect the progress of the project in the future. The reason of changing topic is that we find out the achievement of the last year fyp student on teletable is not as good as they expected, as the teletable involves a few of difficult stuff, and limitations. We do not have much confident to deal with this project, and therefore we finally drop it.

On the other hand, IPhone application development seems to be more interesting and popular. Although we waste a week for our fyp, but we still think that it is worth.