Need your advice for board game project

Monkey Forums/Monkey Beginners/Need your advice for board game project

Corné

(Posted 2016) [#1]

Greetings! I'm keen to build a prototype board game and was hoping the Monkey community (tribe!?) can give me a few pointers please. I have some coding experience (though rusty) and am looking to put something fairly quick & dirty together. Here's some background :

The high level concept is to have a static 2d board (play area) which may or may not exceed the screen area (so panning may be required, but I can do without at first). Then I need to be able to move tokens (sprites?) around on the board. Think of something like the board game "Risk" and you have a good idea.

The board is divided into "zones", so I also need a way to recognize which zone a token is being moved/dropped to/from. The challenge is that my board (map) is a big bmp/jpg essentially and not a structured tile type area - so figuring out a way to know exactly which "zone" a token is being dropped (or picked up from) is a challenge. "Zones" on the board are not square/hex, but are effectively unstructured shapes bordering other unstructured shapes. If you have played games like Europa Universalis, you will understand what I mean - zones are countries/provinces/etc. on a map.

My questions for your input (pretty please):
1. Is Monkey even a good choice for me to use for this project? Do yo know of something more suitable? I do want to build in some basic AI and will do some list/array based data management - so I will need the ability to program some "intelligence" into the game, eg. a simple tabletop simulator won't give me the power to automate the things I want to. My programming experience is mainly with Basic / Blitz (not 3D) / Pascal / VBA / SQL.

2. Assuming Monkey is a reasonable development tool choice here, should I consider using Pyro as well? My game will need a few GUI controls and text - probably more than your typical "monkey only" type 2d game.

3. What technique should I look into for solving the "recognise the map zone" problem? Got any sample code to share or point to? I'm happy to share more details to describe my challenge here, if needed. In a nutshell, I want to use a non-tile based map - so how do I recognise a click anywhere in an entire "zone" on the map? (For example, if you imagine a 2d map of the entire UK, how would I recognise that a mouse click is somewhere in England, and not in Wales/Scotland/Northern Ireland...?)

Thanks in advance for your input on above!

Gerry Quinn

(Posted 2016) [#2]

1. Monkey is just fine for this.

2. Can't help you, I just use pure Monkey but it's quite possible that a framework such as Pyro would save you trouble. You can certainly do your game either way.

3. One approach would be to have a second map image with a different colour on each zone that identifies it, Then convert this into an int array using ReadPixels. It will then be easy to find out what zone a click on the main image is in. The simple coloured map will be a key for the main map which could have pictures of mountains, forests or whatever.

Since ReadPixels uses the render buffer, this might be a bit tricky if your map is large, but you can do it in sections and stick them together, or even use a smaller map. And of course you could do it in dev and just release the game with a pre-generated key array.

You'll also probably want a list or array of all zones giving information about which zones are adjacent to them. That will also constitute a kind of abstract map that your AI will use for pathfinding etc. In fact, for the AI this will be the real map.

Corné

(Posted 2016) [#3]

Thank you Gerry! I like your colour mapping idea. Does Monkey have support for graphic "layers"? If so, I could have the visible map in one layer (which pretty much stays static and visible) and the coloured zone map in another layer (hidden from view and not rendered). Would I be able to perform ReadPixels on a "hidden" layer like this?

Gerry Quinn

(Posted 2016) [#4]

No, you'll need two separate images, as far as I know. You convert the key image into an int array using ReadPixels, and then you don't need the key image any more.

Say your key image is 800 x 600. On a first call to render, you draw the image and use ReadPixels to make an int array. Here is a very simplistic view of how the code could look.:

		' Call at start of OnRender()
		Method PrepareKey:Void()
			If key.Length() > 0
				Return
			End
			DrawImage( keyImage, 0, 0 )
			key = New Int[ 800 * 600 ]
			ReadPixels( key, 0, 0, 800, 600 )		
		End
		
		' Call on mouse click
		Method GetZone:Int( xMouse:Int, yMouse:Int )
			Local colour:Int = key[ xMouse + 800 * yMouse ]
			For Local i:Int = 0 Until zoneColours.Length()
				If zoneColours[ i ] = colour
					Return i
				End
			Next
			Return -1					' Error
		End

PrepareKey() will return immediately if the key has already been prepared.

I'm ignoring various graphic offsets and such like that you may have. I'm also assuming here that the key map fits in the render buffer. If it doesn't, you'll have a few slightly clunky extra bits to write, or else you'll could use a smaller map and adjust the mouse calculations. But anyway, the above will give you an idea of how it could work.

Corné

(Posted 2016) [#5]

This is awesome Gerry, thanks so much! I'm thinking it may be best to write a separate "key generator" program which will take a colour zone map and create a datafile with all the zone data. Then in the main app, I'll read this file and create my array into memory for reference during execution.

Thanks again - much appreciated!

Gerry Quinn

(Posted 2016) [#6]

That's probably what I would do too - you know the size of the buffer on your dev system and that it's certainly 32bit colour. So you can be sure in advance that everything works, and if you have to stick sub arrays together for a large image, you don;t care how long it takes. You could also do the colour to zone conversion in advance, saving calculations and possibly memory in game.

Good luck with your game - happy to help!