Help With Detecting Color Matched Actors

Hapy00Hapy00 Member Posts: 16
edited August 2012 in Working with GS (Mac)
Hey guys. Reaching out for more help once again.

I am doing a game that has colored blocks that I want to color match, ala Bejewled. I basically have the entire game complete except for the color matching system (no, it's not a Bejewled clone, but I would like color matching). I have a play-surrface that is 9 Rows high, by 6 Columns deep. I have successfully detected color matches through a few different means, but they are all processor heavy and drop my FPS to ridiculous lows. My problem is detecting the color matches quickly and efficiently. BTW, I am shooting for an iPhone 3GS as my min. spec, and this what I test on.

Solutions I have attempted: Statically placed Detector Actors in each grid position that record each Blocks position in relation to each other (a zillion Actors on screen; not good), A Detector Actor that teleports to each grid location that records each Block position in relation to each other (takes an incredibly long time to process, and is way to slow) and a Detector Actor that shoots across the screen detecting each Blocks position in relation to each other (this one didn't quite work due to the Detector needing space in between each Block it came in contact with).

So, I am asking the community if anyone has any ideas on how to do something like this. This would be incredibly simple if I could start a Rule with a Table lookup, but I can't. And even if I could, it would still require upwards of 150 Detector Actors in play at all times (AFAIK I would need Detectors for Rows and separate Detectors for Columns). My game is REAL close and I would love to get color matching in and working. I really don't want to have to give up on it as a mechanic for the game.

Any help would be greatly appreciated!

Comments

  • RThurmanRThurman Member, Sous Chef, PRO Posts: 2,881
    edited August 2012
    These kinds of games are usually done with arrays (Tables). When the array is updated, then the actor that corresponds to each particular cell value is updated. That way, all the program needs to do is compare cells in the array (and not individual actors in the scene). Its a much more efficient way to do things.

    As it is now, you've got yourself in quite a little pickle.

    I suppose you could still try to get a Table working by going back to your detector idea. That is, each grid area on the scene would have a detector that feeds the current color value back into its corresponding cell of the table. Then the table cells values can be checked for adjacent matches.

    The detector actors don't need to constantly update. They just need to do their thing when movement stops and all the actors are in their current position. The frame rate will drop pretty low, but it will only be low for a fraction of a second. (Then you turn detection off. And the frame rate resumes at its normal speed.)

    Once you have the table updated, you can then check the cell values for matches.
  • Hapy00Hapy00 Member Posts: 16
    Thanks for the suggestion, RThurman! I had thought of a similar idea previously, but I was unable to figure out exactly how to do that last part:

    "Once you have the table updated, you can then check the cell values for matches."

    And what I mean to say is, I have not been able to figure out a way to do this where I can just check the Table itself for color matches. I can write to the Table with the Detectors, yes. But once the information is there I have no way to access it (easily).

    Here is how I would see it:

    Rule - If overlaps or collides with a Red Block
    And if Detector Check is True (this would be when I turn them on for a split second).
    Then, Change Attribute - Write self.Position X and self.Position Y to the Color Match Table.

    But, then I have no idea where to go from there. I cannot begin a new Rule that asks for a Table position (for instance, Rule - if Table Cell Value = 37, then do...). It would make more sense to just have a bunch of Attributes that get changed to the color value (1 for Red, 2 for Green, etc...), and then compare those color values against each other.

    Of course that would be a mountain of data entry, a mountain of Attributes and a very high chance for bugs.
  • RThurmanRThurman Member, Sous Chef, PRO Posts: 2,881
    Each 'detector' actor would need to correspond to a cell in the table. On signal, the detector actors would need to put the color of the player actor into each cell of the table that corresponds to the detector's position. That way you end up with a table with color values in each cell.

    Then you check each cell against its neighbor to see if they contain the same color value.
Sign In or Register to comment.