Using A Dynamically Generated Grid - Two Questions

Mack_Dundee

I'm experimenting with a game that allows the player to position parts of a road/path in a variety of ways. Basically, I have a start and a finish road piece and the player can connect them as they choose. Some pieces of the road that can be manipulated are straight, some are turns, etc. Think of something like "Carcassonne." What I'm trying to figure out is how to "tell" (or check) that each piece is compatible to it's neighbor and that the end of the path is closed.

So, as I see it, there are two issues:

1). If a piece of road goes from left to up (I don't want the player to be able to rotate any pieces) then it could check the grid spot to it's immediate left and the grid spot directly above for a compatible piece. If one were to create a placeholder (or grid spot) using an actor, this could be accomplished with collisions.

For instance, if the actor that acts as grid spot x=5, y=6 collides or overlaps with a road piece actor that contains the tag "up" then use a scene attribute to tell grid spot x=5, y=7 (the grid spot one above x=5, y=6) to check that a "down" actor tag (to match up with the " up" tag positioned one spot below) is colliding with it in order to complete the level.

The checking of proper positioning could be done at the grid spot actor level (or even the road piece level) using simple booleans such as inputDown and outputDown. Have a rule check that both input and output booleans are "true," and if so, at the scene level an attribute called something like completedRoadPieces could increase +1. When completedRoadPieces and total road pieces match in number, the game could continue.

(By the way, the reason I chose tags like "up" and "down" is that there could be pieces where the road path goes from not only left to up, but also left to right or left to down and so a simple single directional tag does the trick.)

Anyway, how would I accomplish the above without using the many grid space actors required using the collision method that I detailed? My preference would be to use a dynamically generated grid for performance reasons.

Joe, from Fire Maple Games, made a very helpful template that dynamically generates a checkerboard, sets each square's color, and gives each square a unique name based on its grid position. The demo can be found at http://gamesalad.com/game/play/74268 or by searching in the new section of Gamesalad for the "For loop DEMO."

But I'm not sure of how to use Joe's dynamic grid to detect collisions (or something similar) in order to track positioning of road pieces relative to one another.

2). As for the checking that start and finish are connected, with collisions it could be done by simply passing a variable from one grid spot or road piece to another. You give "start" an attribute like pathCheckStart at the scene level and set it to "true". Each of the other grid spots would have scene level attributes like pathCheckRoadGridspot1 and so on, but they would be set to "false". If "start" has a road facing right, then the grid spot to the right would check that it has a road piece that points to the left. If both conditions were met, the grid space to the right of start would change it's unique pathCheck boolean to "true". Once "finish" is set to "true," the road is complete.

Doing this with a dynamically generated grid is not something that I have quite wrapped my head around. Is there a way to communicate between two dynamically generated grid sections? I imagine a control actor might be needed, but I'm not sure.

Maybe there is a way to do everything at the road piece level using math. For instance, a road piece could check to it's immediate left by going -1 (guessing) in the x direction of self. Does that make sense?

Any help or suggestions would be appreciated. Thanks for your time.

old_kipper

I wouldn't use collision but grid state as an attribute integer for each tile at a scene or game level. Then use a check of self position to organise the check of neighbour's attribute state. There will be some custom set ups for the instances within the prototype but I would suggest strongly that you work towards only working within prototype.

In version in 9.4 and 9.5 I successfully populated a scene with tiled actors with a spawn behaviour out of a actor to form a grid with each actor 'projecting' the next into the next vacant spot, and filing rank and file. This gave me accurate positioning without the need for hand positioning and allowed changes in size of tile actors. It also was so fast that it is not noticeable at the start of the scene, but this maybe dependant on the size and numbers of actors. But I would warn you though that i had problems with the instances with the coming of 9.6 and had to rebuild and drop out spawned instances and revert to placed actors. Bring on 9.7

I guess i am not responding directly to your questions but the info might be useful

kipper

TheHoogler

Hey, check out the DBA (Deep Blue Apps) traintrax template. It works pretty well and might give you some ideas on how to accomplish this (I'm putting together a dynamic rail building system using this template)

BSideGames

Yes get DBA traintrax template, works great and is easy to customize. I got it to look at his code and will be using parts of it in my next game

Mack_Dundee

Thanks for your response, Kipper.

old_kipper said:
I wouldn't use collision but grid state as an attribute integer for each tile at a scene or game level. Then use a check of self position to organise the check of neighbour's attribute state. There will be some custom set ups for the instances within the prototype but I would suggest strongly that you work towards only working within prototype.

Kipper (or anyone), could you explain what you mean by checking grid state instead of collision? How would I check for self position to organize the neighbor's attribute state?

Would you suggest spawning a tiny transparent contact actor in each grid spot location to check for the grid state (or even collisions) with the road tiles? Basically, instead of adding the text and color (either black or white) in the "For Loop DEMO" mentioned above, I could spawn a tiny contact checking actor in each grid position? So, the tiny actor that spawns at position 1, 1 (x,y) would act as a sort of placeholder for that position.

Mack_Dundee

Thanks Hoogler and BSide for the template recommendation. I wasn't familiar with the Train Trax template.

Actually, I am able to move the pieces of track around and have the train-like actor "react" based on the track type beneath them. To continue, using the elements of the Train Trax template, let me try and simplify what I am trying to accomplish.

In the Train Trax video (found at http://www.deepblueapps.com/Deep_Blue_Ideas_Ltd./GSTemplateTRX.html ) when the tracks are separated, the train will continue forward over empty space. I want the player to be forced to fill in any missing gaps in the track using a compatable piece. I also want the player to have a set start and finished piece of track that they must link. Whether the player accomplishes the link in ten pieces or eight pieces of track is fine and adds another layer of strategy. Finally, I'd like all open-ended track pieces to be closed. So, a piece shaped like "+" would need to connect with a track piece to it's top, it's bottom, left and right. When each of these conditions are met, the train would then progress from start to finish, in a visual style similar to Train Trax.

I hope that helps to clarify.

If I can ever figure this out, I'll hopefully be able to make a template out of it to upload to Gamesalad to help other users. I'm still not quite there yet.

TheHoogler

I'm going to work on this, and I'll let you know of any progress. My goal is to make the train move back and forth between two points (once the track is assembled) which requires some tinkering. Since I own the template, I'll look to see if there's any easy way that the game can "check" that all rails are connected and closed. If the train is actively moving regardless of track completion, it should be easy to "check" if the train is touching a track actor, and if not, stop motion. But....Just for clarification, your "train" wouldn't move until the railroad is complete, right?

old_kipper

In answer to your question/s, I would firstly say that I would have actors in place, filling the grid to start with (or spawned at the start of the scene) and these can display as an empty space by switching the alpha. WHen you have the player drag a piece I would not actually have them place the piece but just drag an piece that when dropped at a grid point it did in fact disappear (return home for recycling) and the grid would display the local piece.

1). explain what you mean by checking grid state instead of collision?

From my reading of the way you want to do this, the track actor has to know the state of the adjacent actors in all directions, or if they are blank grid/edge of grid. The passing of that information needs each grid space to send to an attribute that is visible to other grid actors (or in the case of edge or empty space for there to be a null value). The moving actor has to make it's path when achievable so has to know that state exists, but while travelling the collisions to switch direction are cool, an underly directional map already would exist so I would use that to organise the route of the actor.

2). How would I check for self position to organize the neighbor's attribute state?

By reading its self position it would then (based on rules governed x,y position) reference the 'surrounding' game/scene attributes, and pass its own state to the attribute for its grid position. these are the directions open or closed, and could be defined within an integer, and would be used A). for the visual display, . for the 'achievable' state of the whole system, and C). for guidance of the train on it's path to the goal.

How you do the 'achievable' search I not thought through yet. But some kind of boolean in each actor fired back from the goal might do it, or even an invisible actor that runs every time a tile us changed, that starts at the goal and tries to get to the start point with search simple algorithm.

All of the above in based on my own experience and I've not put this into practice. There may be neater ways of doing it and I may have missed a simple logical way of doing it, but it is quite a complex problem.

good luck kipper.

Mack_Dundee

Thank you so much for all of your help, guys! I really appreciate it.

Hoogler, to answer your question, yes I do want the track to be completed before the train actor moves as the final scene animation. Otherwise, the play could just nudge the train a little at a time using only a few track actors that could be repositioned multiple times.

That is, if I need to ultimately move the train five grid places to the left, I could just use two track pieces that go left to right. I place one left to right piece down next to start and my train could move onto it. I place another and my train moves onto it. I would now have moved two blocks to the left from start. Since I have passed the first left to right tile onto the second, I no longer need it to remain in the first grid spot. So I could just move the first track piece to grid spot three and move my train onto it. The second track piece could go to grid spot four and then track piece one could go to grid spot five. At this point I could have moved five grid spaces to the left with only two pieces.

I think the game would be a lot more challenging if players would have to consider how many track pieces are left and how to most efficiently reach their goal. Sometimes their goal would not be direct. They may really want a left to right piece but instead are left with other bits of track that will force them to loop around indirectly to reach the goal.

Also, just to clarify, each level would have a predetermined start and finish position as well track pieces available. I wouldn't want to use random track pieces because you could end up with an unsolvable puzzle.

Kipper, I believe I remember seeing a Gamesalad template that does what you say in your first paragraph. I'm actually at work now so I can't work on this for a few more hours at least. When I get home I'll be able to examine the other aspects of your response more closely.

Hoggler, you are too kind to actually try and work on this. Thanks a lot!

One last thing, here at work I've been thinking about this all day. (I had been working on the mechanics of the game for a few weeks before posting.). Anyway, I remember seeing a template that could help. I don't recall the name of the template off the top of my head, but it allows the player to place red circles onto a grid and sends that circle's grid coordinates to an actor on the right that displays those coordinates. Instead of sending those x and y coordinates to the display actor, I could just send them to the track actor itself. Inside a track actor that has a left-sided connection (a train can enter or exit it on the left) could have something like a left_check attribute. This attribute could take self.position -1 in x (since x is horizontal and a minus would be left in the horizontal) and leave y unchanged (since we are checking one direction per attribute - just left in this case).

Left_check would have the coordinates of the grid space to it's immediate left. It could send this value to a scene attribute called something like tags_right. Tags_right could have a list of each grid space to the left of all track pieces with a left-sided connector. (The reason to call it something like tags_right is because a right piece of track at x=1 connects to a left piece of track at x=2. So, a right piece should be to the left of a left piece in order to connect.)

Each individual track piece could check the scene level tags_whatever (ie, tags_right) in the direction with which they are looking to connect. If it's a match, then both connecting track pieces would set a few simple booleans to "true". A scene level integer could keep "score" of open verses closed track pieces.

To clarify, Each individual piece of track would send out it's own check_whatever direction it has (output) against the scene level tags_whatever in the direction it needs (input) to make a successful connection. The track piece would then set attributes accordingly.

Finally, my question now is how do I get the block to pick it's individual coordinates from a list of multiple coordinates in, say, tags_right. I imagine you'd have a rule within the track actor that says, if attribute tag_right contains exactly current self coordinates then do stuff. I need a way for the track piece actor to check to see if it's current grid coordinates are on the list.

I can't remember if non-text attributes within rules have the ability to look for (or search) a specific value(s) such as a number. Each track piece would retain it's own personal grid coordinates in an attribute (ie, my_coordinates) which is how we would derive the positions of their respective "neighboring" grid spots. For example, a track piece with my_coordinates of 1,2 (x,y) would check coordinates 1,1 if searching to it's immediate left. So, in this example, the track piece at 1,1 would need to pick out from the list in attribute tags_right it's own coordinates of 1,1. I imagine it can be done, but I'll have to check when I get home.

Is anyone still reading at this point? I know, this one is a doozy. Thanks again, guys.