The Development II of Our Game:Parade

It has been one week since the last update, and I have really added some new functions. This prototype maybe small and simple, but I think this could absolutely show the idea of our team and people are able to get understand of the design.

For this time, I will show the function of happiness bar movement and the power-up buttons.And about the collision function that I mentioned last time, I would talk about its update.

1. Collision Update

Last time the original collision was that Mario stopped when got stuck. During this week, I added the collision event which shows the specific meanings (tire broken and burst fire hydrant). So when the function of collision detected there is a crash accident, it will shows the accident icon and you can hear the sound of that. I will show this with following pictures first:


2. Happiness Bar

This is very important for this game. Because each game has its obstacles. These two obstacles above I talked about will not be a real problem for the player if we could not use them to prevent players from winning. Just to address it again, this game is about parade. The troubles along the way are not big deal for parade itself, but when coming to the audience, it turns to be a disaster. We have designed a happiness bar to record the audience reaction to the parade. And when some random events happen, the audience would get unhappy. If the happy point falls to the end, the game is over.

For this design, I made a function for happiness bar movement. When the crash event happens, the collision detection will send a signal to the happiness function and then the happiness point will fall down a little. Just like:

  • function b_move()
  • print(“j”)
  • print(j)
  • local x2 = stepstick[j +1]
  • local y2 = -655
  • local b_x = stepstick[j +2]
  • local b_y = -655
  • level_hit.level_hit2()
  • level_hit.level_hit()
  • MOAIThread.blockOnAction(level_initiate.prop14:seekLoc(b_x,b_y,level_begin.distance(b_x,b_y,x2,y2)/100,MOAIEaseType.LINEAR))
  • j = j + 1
  • end

And the effect looks like this:

happy bar unhappy bar

3. Power-Up button

Up to now, I added two power-up buttons. And there will be three at last. The first button is the repair button, which could solve the tire broken trouble but would not get the happiness point higher. And the second button is for cheering up the audience to get higher happiness point with the firework. You will find these when click these two buttons:



As for the third power-up button, I would add the candy button, which is similar to the firework button getting the audience happy and crazy (especially for the children).

So this is what I have done so far, and I really want to say thanks to our  team members. They gave me courage and also provided me with useful information about the MOAI. Thank you! And keep working!

The Development I of Our Game:Parade

So far we have developed our game for over a week, it is such a nice experience as we saw the idea was born and then put it into detailed design. And through one-week MOAI learning, I could say now some functions of the game have been came out. Now I will talk about the game we are designing and what I have learnt about MOAI.

1. The world,the view and the screen

For the beginner, it is easy to get confused by these three concepts: world resolution,view resolution and screen resolution, especially the writing in the book Developing Mobile Games with Moai SDK could a little bit confusing as the author used the world_resolution for representing View Resolution.  It is important to figure out these three concepts,  particularly when the game is 3D type. I will use a picture to explain these, here is the picture:


World Resolution is for the game world, you can say there is no boundary if you want, but technologically it’s the resolution of the game background map. And the View Resolution is for view that captures this world, we could compare it as a camera. And the third one is Screen Resolution, it is the resolution for the device showing this game (computer,TV,mobile phone etc.) So remember the coordinate we calculate is based on the World Resolution, not the Screen Resolution nor the View Resolution. Let me use another picture to address this:


The camera ( View) captures the view of the game world ( World Resolution) and transmits it to TV ( Screen Resolution). Even the screen is what you see in the end, but this is not real. Remember we are building this world, so focus on the game world!

In our project, the code is like this:

  5. — opint the main screen
  7. –setup viewport
  8. viewport =

And the game window is like this:


2. Now let’s move and hit

One of the functions we have to achieve is to make the object move and collision could be detected when happening. First I will make sure the objects (the parade) move on the right track of the map. Then I will add the function of detecting the collision.

For a simple implementation, I calculated the turning point of the map and used the function seekLoc to ensure the parade is on the correct path.

for  function seekLoc ( MOAITransform self, number xGoal, number yGoal, number zGoal, number length [, number mode ] ), the coordinate of the turning point x and y is the xGoal and yGoalnumber length is the time length of moving. I used the function of  distance(x,y,x1,y1)/velocity to keep the object in steady speed. And these coordinates of turning points are stored in the table step{}. Here is part of the code:

  1.  local step = { -580,700,-580,350,-580,50,540,50,580,50,580,20,580,-550,1000,-550}
  2. while not click do
  3. print(“x”)
  4. if MOAIInputMgr.device.mouseLeft:down () then
  5. while(i<8 ) do
  6. x1 = step[(i-1)*2+1]
  7. y1 = step[(i-1)*2+2]
  8. x = step[i*2+1]
  9. y = step[i*2+2]
  10. MOAIThread.blockOnAction(level_initiate.prop6:seekLoc(x,y,distance(x,y,x1,y1)/200,MOAIEaseType.LINEAR))
  11. i = i+1

It is obvious that each moving section is fixed by two points, which is the start point and the end point.  So when the game begins and there is a click action, the super Mario icon ( I just used this for test. Our object picture would be much better) will move. This is the screenshot of this:


And I place two obstacles for hit testing as we can see in this picture. When the program detects the collision, Mario will stop for a while and then moving. This is achieved mainly by this function:

  1. function checkhit(x,y,prop)
  2. local x1 = x
  3. local y1 = y
  4. local x2,y2 = prop:getLoc()
  5. return level_choose.distance(x1,y1,x2,y2) <= 50
  6. end

And if Mario and the obstacle is really close within 50 pixels, then bing! Mario gets hurt and stops for a while. The detailed mechanism of this function I will talk about later, which is related to thread handle. And I would like to show how Mario gets stop by pictures:


I know the effect is not good but Mario really gets stuck by this obstacle. And he will stops for about 3 seconds and then keeps moving.




So this is so far I have done, keep working!