Puzzle Game. Does using MOAIGrid or MOAIPartition?

[jfcalvo]

Hello everyone!

I'm developing a new puzzle game with Moai and I have some questions about to (and how) use MOAIGrid or MOAIPartition.

My puzzle game consists in a grid of 6x16 (Width x Height) colored square blocks. When the game starts there is no blocks in the screen, all the grid of blocks go up slowly from bottom to top pixel by pixel. The user will move blocks inside the grid (exchanging the position of one block to another) to match colors and make the blocks to disappear. Is interesting to note that the numbers of blocks that appear from the bottom of the screen will be infinite until the user cannot make the blocks disappear and the blocks touch the top of the screen so the game is over.

I would like to know some opinions from more experienced Moai users than me about the possibility of use MOAIGrid or MOAIPartition (with MOAIProp). As far as I know it is possible to create a rect MOAIGrid of 6x16, it is possible to move the grid slowly (pixel by pixel) from bottom to top but I am not sure if will be easy to integrate the MOAIGrid with blocks that are moved by the user (inside the Grid). Another problem is the infinite nature of the blocks that appear from the bottom of the screen, I don't know how to solve this with MOAIGrid.

On the other hand we have MOAIPartition using a MOAIProp for every block (MOAIPartition to detect picking). I have read that this is by far less efficient that a MOAIGrid but I feel this solution more natural and easy to implement. But I don't know how will work Moai with 96 MOAIProp in the screen.

Has anybody some idea/opinions about how to solve this problem? There are some other better alternatives? Should I use MOAIGrid of MOAIPartition with normal sprites?

Thanks!.

[pygy79]

I'm going to bump this... I can't help you, but it will give you some more visibility...

[sgeos]

MOAIGrid or MOAIPartition.

Either can be made to work.

all the grid of blocks go up slowly from bottom to top pixel by pixel.

You can use a grid for this. Loop the grid and scroll your static map.

The user will move blocks inside the grid

You could overlay a second grid above the first one if all the blocks always move in the same direction. Most of this grid will be transparent. When you move blocks, do this:

• Remove the blocks from the static grid.
• In the same update add the blocks to the same place in the movement grid.
• Scroll the movement grid over a number of frames.
• Remove the blocks from the movement grid.
• In the same update add the blocks to the same place in the static grid.

If you need to swap the blocks, it may make more sense to use props. The program flow is similar:

• Remove the blocks from the static grid.
• In the same update add the props to the same place above the static grid.
• Move the props over a number of frames.
• Remove the props.
• In the same update add the blocks to the new location in the static grid.

Another problem is the infinite nature of the blocks that appear from the bottom of the screen, I don't know how to solve this with MOAIGrid.

As you scroll the grid (if you go that route), you need to keep track of the current bottom row. Just overwrite it with the new blocks that will appear at the bottom of the screen. If you can display a total N blocks vertically when they are not moving, you will need to have a grid that is N+1 blocks high.

• Add new blocks to the off screen buffer regionwhen the grid is aligned with the screen.
• Scroll blocks a pixel at a time.
• Game over if any blocks would scroll off the top of the screen (into the new buffer row).
• Repeat.

I am not sure if will be easy to integrate the MOAIGrid with blocks that are moved by the user

You will need to handle input processing (which block was touched) and animation on your own. The grid is a tool, not a complete solution.

I feel this solution [MOAIPartition using a MOAIProp] more natural and easy to implement. But I don't know how will work Moai with 96 MOAIProp in the screen.

You may find it easier to work with a partition depending on what you are trying to do. Programmer time is often more important than execution time. You will find out if 96 props is too many, but I highly doubt it will be. (96 particle systems on 96 props with rotation, scaling and color transitions might be pushing things.)

Remember, model, view, controller. You should store your game model and build your view (what hits the screen) using that model. Using the view to store model is doing things backwards.

[jfcalvo]

Thank you very much Sgeos for you reply. Your information about the use of MOAIGrid is very interesting.

The truth is that I am now using a partition with a prop for every block in the screen and as you have said Moai don't have problems showing a big number of blocks in the screen at the same time (I'm right now trying my solution using the iOS host). I don't have yet a complete solution for the game mechanic but I feel that if I introduce grids the solution will be more complex so I'm using now only props and a partition.

I have changed the game mechanics to a more interesting gameplay (In my own opinion). The game is now landscape oriented and I have two different groups of blocks, one on the left and another on the right. Do you know if it is possible to use two partitions (in the same or different layer) to facilitate the picking of the props by the user? I have been trying without any luck and I don't find any sample about this issue in the MOAI samples folder.

Here you have a screenshot of the progress:

Remember, model, view, controller. You should store your game model and build your view (what hits the screen) using that model. Using the view to store model is doing things backwards.

Very interesting recommendation. I have never thought about the MVC pattern in games programming but I will.Do you have some recommendations to use this pattern in Lua with Moai?.

Greets.

[sgeos]

Re: Two Sets of Blocks
The code is untested, but I do not see any reason why something like this would not work. The key point is that you have two copies of everything, and you check input against both copies. Alternatively, you could put all your blocks (left and right side) into the same partition.

Code: Select all

1. -- process input every frame during update


2. function update ( pState, pContainerLeft, pContainerRight )


3.   local touch, x, y = Input.touch ( )


4.  


5.   if touch then


6.     pContainerLeft:touch ( x, y )


7.     pContainerRight:touch ( x, y )


8.   end


9. end


10.  


11. --- in Container.lua ...


12. function new ( pParams )


13.   local result = {}


14.   -- setup result using pParams


15.   -- add a layer, partition and blocks to result (i.e. each container)


16.  


17.   -- container object will respond to touch


18.   function result:touch ( pX, pY )


19.     local pick = self.partition:propForPoint ( self.layer:wndToWorld ( pX, pY ) )


20.     if pick then


21.       -- move blocks


22.     end


23.   end


24.  


25.   -- return new container object


26.   return result


27. end

Re: MVC

In my game I have any "enemy" class and an "avatar" class. "Enemy" objects hold an "avatar" object and communicate with it via the object's methods. The "input" singleton collects input and that is passed into the "enemy" objects who forward it to the "avatar" for processing. I actually pulled the code from that part of the project and reworked it when I posted the above example. Here is an example:

Code: Select all

1. function new ( pState, pParams )


2.   local result = {}


3.   -- initialize object with pParams


4.  


5.   -- initialize child objects


6.   result.position  = Position.new ( )


7.   result.avatar    = Avatar.new ( pState, params )


8.  


9.   function result:touch ( pX, pY )


10.     local avatar  = self.avatar


11.     local moveset = self.moveset


12.     local pick    = avatar.partition:propForPoint ( avatar.layer:wndToWorld ( pX, pY ) )


13.     if pick then


14.       -- respond to input


15.     end


16.   end


17.  


18.   -- return new container object


19.   return result


20. end