Need a little logic advice for a tile/ grid based puzzle game please...
I'm making a puzzle game in the style of Tetris Attack (a.k.a Panel-de-Pon)/ Pokemon Puzzle League/ Poker Smash, so if you know those games, you'll know what I'm going on about below. It's basically a tile switching, match 3 (or more) game (PPL vid: https://www.youtube.com/watch?v=SH6rzYqXlb0&t=952s)
So I've come quite far and it's coming together but I'm really fighting the thermo on gameplay. With a full grid of tiles I'm running near enough 100 tiles (and after a lot of testing, I think the grid does need to be that big). Those consist of 5 different tile types that are all being emitted into the grid. Each tile has exactly the same logic, with the exception that a red tile has a 'tag_Red' tag, a blue has a 'tag_Blue' tag etc...and each has trigger zones looking for other tags of its own colour.
So while I've done a lot of work to simplify the tile logic as much as possible, even with what little I have in place I find that by the time the grid is close to full, my gameplay is running at about 90% and I'm getting slow-down messages........and I haven't even added two of the main game mechanics or any scoring system yet!
I think one of the main issues may those trigger zones that I mentioned above. Each tile has one looking horizontally to see if its two right-hand neighbours are the same colour as itself. And there's another zone looking up to see if the two tiles above it are the same colour...and these zones are the basis of my 'Match 3' mechanic.
I can't think of another way to implement the match 3 system but I'm sure that if I could find a way of doing it that didn't involve giving every single tile those 2 trigger zones, it'd probably save me a lot of gameplay thermo. So I'm wondering if anyone else may have an idea of some other way to achieve it that could be handled by the central game logic, rather than adding the logic to all the tiles.
Would really appreciate any help and thoughts on this as I'm close to putting something together that should work really quite nicely.
-
I had similar issues in a grid based procedural level generator that used two trigger zones per tile also. The trigger zones were a huge draw on my overall gameplay thermo and slowed everything to a crawl, even edit mode became too slow to manage.One suggestion might be to try remove one trigger zone leaving just one on each block. Then add a keyframe and use the grid to rotate the block 90 degrees. This will also rotate the trigger zone. Power the keyframe via a global timer (just one timer) and use wireless transmitters and receivers. A timer set to 0.1 should all work fast enough to check in the horizontal nd vertical for match threes. This is only a suggestion as I don't know if it help at all since it does require more logic, but less trigger zones. Let me know if it helps.
-
I was looking at something similar... but completely different to this. The main thing that takes up gameplay is the logic. Zones themselves don't take up any more thermo, though they may have performance costs. But I'd definitely look at reducing the amount of logic existing at any one time. By this, I mean emit the logic when it is needed, and destroy logic when it is no longer needed.
For my instance, I was trying to create cans that move physically and have other logic to them as you interact with them. The creator that was using something like that had just put all the logic into the one can, and then originally had them cloned a couple hundred times or something, which took a ton of gameplay because of the complexity of the logic.
They then tried emitting the "real" version as you near them, but then that just skyrocketed the thermo as you wandered around the place without cleaning up after itself.
So in my version, seen in "Efficient Physical Cans" (https://indreams.me/scene/dYhHnHYNzkB), I have two versions of the can. One is a "dead" can with no physics, collision, nothing. All it does is detect if something is happening nearby that may require it to become "alive," at which point it emits the live can and destroys itself. The live can does cool logic stuff, but also has a cooldown that starts when it thinks might not need to be physical anymore. When that time is up, it emits a dead can and destroys itself again. (In the demo scene, the physical version is a lighter colour so it's easy to see what's going on.)
So then, most of the cans that are ever in the scene are really cheap on thermo. When necessary, they completely swap out to become live and use more thermo. Until they cool down and become dead again and use less thermo.
In the scene, I have a couple hundred dead cans with no problem whatsoever and the live cans behave as expected. The scene itself is pretty low thermo. And during gameplay, thermo goes up and down as necessary, using as little thermo and logic features as possible.
For your case, you may be able to use a similar method. Emit the "interactive" logic version when the player can interact with it. Nearby tiles may swap out for interactive ones too so they can check and react to any changes made. That kind of thing.
Hope this helps. I can explain the logic in that scene some more if anyone would like me to. -
Thanks both, that's given me some avenues worth looking at.
-
(I'm just winging it here), but if you found a way to use 'look at an angle' around the center of the piece, with dropouts at angles other than 90° with a 'rotator' to move the 'look at an angle' into position. Note: if this works like I think does, please tell me.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.