Matching Engine

Monkey Forums/Monkey Code/Matching Engine

Why0Why(Posted 2012) [#1]
I like the way matching is done in the game Dungeon Raid and have enjoyed the game a lot. I am planning on using a similar matching style, but making a much deeper game. This is the base engine. It draws a grid and populates each cell with random numbers from 1-4. Drag your mouse over 2 or more matching adjacent cells to complete a match. Once you release the mouse button, it drops the above cells down and repopulates empty cells.

The community has been so great here that I wanted to post some code that might help someone else. I have commented it fairly well, if anyone has any questions, feel free to ask.




Gerry Quinn(Posted 2012) [#2]
I usually make a Game class (handles game logic) and a GameWindow class (handles UI and drawing). The GameWindow passes user actions to the Game. The App sets the other two classes up and calls Update() and Draw() functions on the GameWindow (and a SetMetrics() function at the start). This separation of functions makes for smaller classes, which is good as your game becomes more elaborate and accretes buttons, menus and suchlike.

I also have handy Point, Size and Rect functions (patterned on Microsoft's old MFC), so for example my GameWindow will have a field cell00:Rect, which cuts down on the number of fields needed. Then I can write (for example):

Function GetCellRect:Rect( cell:Point )
	Local rect:Rect = New Rect( cell00 )
	rect.Offset( cell.x * rect.size.w, cell.y * rect.size.h )
	Return rect
End


That said, your Grid is fine too. To be honest I find myself writing patterns like the above over and over and I always say to myself 'Why not have a Grid class'. On the other hand I also don't mind laying down a bit of boilerplate of this kind when I start a new project - it sort of eases me into it.


Gerry Quinn(Posted 2012) [#3]
I usually make a Game class (handles game logic) and a GameWindow class (handles UI and drawing). The GameWindow passes user actions to the Game. The App sets the other two classes up and calls Update() and Draw() functions on the GameWindow (and a SetMetrics() function at the start). This separation of functions makes for smaller classes, which is good as your game becomes more elaborate and accretes buttons, menus and suchlike.

I also have handy Point, Size and Rect functions (patterned on Microsoft's old MFC), so for example my GameWindow will have a field cell00:Rect, which cuts down on the number of fields needed. Then I can write (for example):

Function GetCellRect( cell:Point )

End



Gerry Quinn(Posted 2012) [#4]
I usually make a Game class (handles game logic) and a GameWindow class (handles UI and drawing). The GameWindow passes user actions to the Game. The App sets the other two classes up and calls Update() and Draw() functions on the GameWindow (and a SetMetrics() function at the start). This separation of functions makes for smaller classes, which is good as your game becomes more elaborate and accretes buttons, menus and suchlike.

I also have handy Point, Size and Rect functions (patterned on Microsoft's old MFC), so for example my GameWindow will have a field cell00:Rect, which cuts down on the number of fields needed. Then I can write (for example):

Function GetCellRect( cell:Point )

End



Gerry Quinn(Posted 2012) [#5]
I usually make a Game class (handles game logic) and a GameWindow class (handles UI and drawing). The GameWindow passes user actions to the Game. The App sets the other two classes up and calls Update() and Draw() functions on the GameWindow (and a SetMetrics() function at the start). This separation of functions makes for smaller classes, which is good as your game becomes more elaborate and accretes buttons, menus and suchlike.

I also have handy Point, Size and Rect functions (patterned on Microsoft's old MFC), so for example my GameWindow will have a field cell00:Rect, which cuts down on the number of fields needed. Then I can write (for example):

Function GetCellRect( cell:Point )

End



NoOdle(Posted 2012) [#6]
On the other hand I also don't mind laying down a bit of boilerplate of this kind when I start a new project - it sort of eases me into it.

Theres only so many times I can write the same piece of code before I start thinking "Why am I doing this?" I already know how to write it in my head so the challenge and fun disappear... I'm grinding code - a bit like questing in MMO's!


slenkar(Posted 2012) [#7]
I usually make a Game class (handles game logic) and a GameWindow class (handles UI and drawing).


NoOdle(Posted 2012) [#8]
I create layers. A layer can be used for anything, background, ui, game logic. Rendered in z order so background could be rendered first, ui layer rendered last. Fairly flexible and works well from the tests I've done. Layers can receive touch events based on a flag and swallow them as appropriate or pass them on to the layer below for checking and so on.


Gerry Quinn(Posted 2012) [#9]
Sorry about the extra posts - I thought I was editing one post but it seems the forum thought otherwise!

"Theres only so many times I can write the same piece of code before I start thinking "Why am I doing this?""

Generally that's true for me also, but setting up very basic framework stuff at the start of a project is stuff I can do in my sleep and it helps me get into the mood. Also if I did a grid framework I'd be saying to myself "This should also do hex grids". Then I would wonder should it be able to clear a basic grid and if so should it be a quadrangle or a hexagon...

So I'd just end up wasting time compared to just writing a few simple methods...

It's the boring non-game stuff like menus that I like to get into libraries and only do once (though they always get new features added in every new project...)


Why0Why(Posted 2012) [#10]
This isn't what the final will look like. I just put all of this here like this so it was self contained. Obviously, graphics, sounds and all of the specific stuff will be organized differently. I just wanted the core logic in place and I wanted something that people could run without adding graphics or anything else.