Newby tries to implement a Board Game
by Oldtree · in Torque Game Builder · 07/06/2008 (5:13 am) · 9 replies
Hi there,
I'm fairly new to torque, even though I have several years of programming in java and other languages under my belt (no game programming but more server - server communication with buisiness logik).
If you want to get an idea what board game I'm trying to implement, you can see a picture of it while playing a prototype at a game convention in I think 2005:
(by the way I'm the guy sitting to the right only half visible). It's a board game created by a friend of mine.
As can be seen on the photo, the game board is based on a hexagonal layout. It seems to me, that hex layouts are not exactly the strongest part of TGB.
What I've done so far is creating a bitmap which correspond to the board in the picture. Because I want to interact with the hex fields of the board, my first idea was to use the polygon - object in TGB and detect the mouse over event via Behaviours. The problem is that the mouse over event is not triggered on the polygon shape (hex field) but on entering the surrounding box (square field) of the polygon.
Is there an easy way to detect mouse over event over such a hex field (or other more complexed shaped field).
My current "workaround idea" is an invisible object hooked to the cursor and detect entering the hex area via collision events (I havnt tried this idea but came up with it while reading the FishGame - Tutorial and learning about the collision possibilities of TGB).
PS: Even though I welcome every response, it would be nice to spare me comments like "use the search" or "this topic was already discussed in great detail somewhere". Please give me a concrete link in such a case. Thanks...
PS2: I have Torque Game Builder without source code, so any ideas changing the source code of TGB are out of my possibilities.
I'm fairly new to torque, even though I have several years of programming in java and other languages under my belt (no game programming but more server - server communication with buisiness logik).
If you want to get an idea what board game I'm trying to implement, you can see a picture of it while playing a prototype at a game convention in I think 2005:
(by the way I'm the guy sitting to the right only half visible). It's a board game created by a friend of mine.
As can be seen on the photo, the game board is based on a hexagonal layout. It seems to me, that hex layouts are not exactly the strongest part of TGB.
What I've done so far is creating a bitmap which correspond to the board in the picture. Because I want to interact with the hex fields of the board, my first idea was to use the polygon - object in TGB and detect the mouse over event via Behaviours. The problem is that the mouse over event is not triggered on the polygon shape (hex field) but on entering the surrounding box (square field) of the polygon.
Is there an easy way to detect mouse over event over such a hex field (or other more complexed shaped field).
My current "workaround idea" is an invisible object hooked to the cursor and detect entering the hex area via collision events (I havnt tried this idea but came up with it while reading the FishGame - Tutorial and learning about the collision possibilities of TGB).
PS: Even though I welcome every response, it would be nice to spare me comments like "use the search" or "this topic was already discussed in great detail somewhere". Please give me a concrete link in such a case. Thanks...
PS2: I have Torque Game Builder without source code, so any ideas changing the source code of TGB are out of my possibilities.
About the author
#2
Edit the objects collision shape, there you can set it to the shape of your hexagon.
Michael
07/06/2008 (8:00 am)
Hi Thomas,Quote:The problem is that the mouse over event is not triggered on the polygon shape (hex field) but on entering the surrounding box (square field) of the polygon.
Edit the objects collision shape, there you can set it to the shape of your hexagon.
Michael
#3
thanks a lot. This is indeed an easy way to solve the problem. Nice to know that the onMouseOver event depends on the collision shape....
Again thanks for the hint...
07/06/2008 (8:24 am)
Hi Michael,thanks a lot. This is indeed an easy way to solve the problem. Nice to know that the onMouseOver event depends on the collision shape....
Again thanks for the hint...
#4
Handle onMouseMove or onMouseDown in your gui and calculate what hex is under the mouse given the screen space or object space coordinates. Basically you could calculate the onMouseOver yourself, but then you wouldn't need a separate t2dSceneObject for each hex-cell. I dunno if thats a concern of yours, but it seems a bit like a bad idea to have all those t2dSceneObject(s). If your current approach is working I wouldn't bother with this.
07/06/2008 (8:35 am)
Heres another idea... Handle onMouseMove or onMouseDown in your gui and calculate what hex is under the mouse given the screen space or object space coordinates. Basically you could calculate the onMouseOver yourself, but then you wouldn't need a separate t2dSceneObject for each hex-cell. I dunno if thats a concern of yours, but it seems a bit like a bad idea to have all those t2dSceneObject(s). If your current approach is working I wouldn't bother with this.
#5
this is an interesting alternativ. For the time being I think I will stick with the easier approach for the simple reason to get my project going.
But your idea is really interesting not only for the reason to use less systems ressources but also to implement one of my later planed features for this game (if they will ever be implemented).
This feature would be a dynamically created game board. The board consists of lots of blue hexes (the water) and several differently colored regions (the lands). Each land consist of several provinces (the actual hex fields). In the first version of the board game, the board was fixed as can be seen in the photo in my top post. The rules of the game has been changed as of now, and the actual game play starts with each player placing lands on the blank board. In that way, the game plays different on every occasion. But for my first version of the game I will implement it with a fixed game board.
If I will implement it with a dynamically created board your approach will deffinitly come in handy...
07/06/2008 (9:53 am)
Thanks James,this is an interesting alternativ. For the time being I think I will stick with the easier approach for the simple reason to get my project going.
But your idea is really interesting not only for the reason to use less systems ressources but also to implement one of my later planed features for this game (if they will ever be implemented).
This feature would be a dynamically created game board. The board consists of lots of blue hexes (the water) and several differently colored regions (the lands). Each land consist of several provinces (the actual hex fields). In the first version of the board game, the board was fixed as can be seen in the photo in my top post. The rules of the game has been changed as of now, and the actual game play starts with each player placing lands on the blank board. In that way, the game plays different on every occasion. But for my first version of the game I will implement it with a fixed game board.
If I will implement it with a dynamically created board your approach will deffinitly come in handy...
#6
www.garagegames.com/mg/forums/result.thread.php?qt=75434
07/07/2008 (4:10 pm)
Check out my post in this thread:www.garagegames.com/mg/forums/result.thread.php?qt=75434
#7
Since this is a regular grid and all the "polys" are really identical there should be a better way to calculate that, but I don't really know.
07/08/2008 (10:19 am)
But you really wouldn't want to run that point in poly test for every single hex. That would be like 200 billion string operations. Well depends how many hexes there are.Since this is a regular grid and all the "polys" are really identical there should be a better way to calculate that, but I don't really know.
#8
If it is just a regular hexagonal grid system, I might suggest trying to use two tile layers placed on top of each other. It is hard to explain without a picture, but you can make a hexagon tile that has twice the width as its height, center the actual hexagon in the image and then fill the layers. Then slightly overlap them.
To determine which hexagon is selected you can do some clever coding, but it should be pretty simple. I wish I had an example, but maybe I will work on something and upload it to TDN for other hexagon tile users.
07/08/2008 (12:48 pm)
It depends when you are doing it. If it is just for the onMouseMove callback there really shouldn't be any dramas. You could, of course, convert that function to source if you're really ambitious. It would take a fraction of a second to calculate that in C++.If it is just a regular hexagonal grid system, I might suggest trying to use two tile layers placed on top of each other. It is hard to explain without a picture, but you can make a hexagon tile that has twice the width as its height, center the actual hexagon in the image and then fill the layers. Then slightly overlap them.
To determine which hexagon is selected you can do some clever coding, but it should be pretty simple. I wish I had an example, but maybe I will work on something and upload it to TDN for other hexagon tile users.
#9
thanks for pointing me to this thread. I tried the algorithm mentioned in "your" thread. It works really well. The advantage of this solution over an approach with collision - shapes is, that it works also with non-convex hulls.
As of now I can't tell which of the mentioned solutions is the most performant one. All I can say is, that the onMouseMove - Event is fired quiet often, and the less coding is processed in such an event, the better it is.
But after all, I'm trying to implement a turn based strategy game and not a real time MMO combat system. So I hope I have plenty of space to make let's say "sub optimal" coding decisions in terms of performance and ressources.
07/08/2008 (1:08 pm)
Hi Phillip,thanks for pointing me to this thread. I tried the algorithm mentioned in "your" thread. It works really well. The advantage of this solution over an approach with collision - shapes is, that it works also with non-convex hulls.
As of now I can't tell which of the mentioned solutions is the most performant one. All I can say is, that the onMouseMove - Event is fired quiet often, and the less coding is processed in such an event, the better it is.
But after all, I'm trying to implement a turn based strategy game and not a real time MMO combat system. So I hope I have plenty of space to make let's say "sub optimal" coding decisions in terms of performance and ressources.
Torque Owner Oldtree
The collision - detection works only if I move my cursor very slowly over the boundaries of my hex - polygon. Once I'm in the hex - area with my cursor and the collision wasn't detected because I moved the cursor to fast, there is no trigger that my cursor is above the hex. So this idea seems to have it's cons...