Digging games
-
@Martin could use small 4x4 tiles, but I don't think you can write to tilemaps on the fly in Fuze
-
@Retrocade_media that depends on how you do the tilemaps. If you have an array of tile numbers (or 2 dimensional array of tiles) then you can. But you have to be careful because array performance suffers with multiple dimensions. I did a proof of concept with a similar thing before but I got completely stuck on how to make the tiles be eaten away rather than vanishing tile by tile. Well, the proof of concept was for something different but it was essentially the same wall that I hit.
-
Ohhh, the proverbial penny has just dropped about how to do this! I wonder how quickly I can knock up a proof of concept.
-
@Martin said in Digging games:
Ohhh, the proverbial penny has just dropped about how to do this! I wonder how quickly I can knock up a proof of concept.
Well don't keep it to yourself. do tell!
-
Well I want to test it first! But my sticking point has always been the eating away of the tile pixel by pixel. Whether that tile is a sprite or an image. But just for once, if instead of a transparent background you give the player a black background with an alpha of 1 then you'll naturally appear to be eating away at the tile as you move and once they are over a certain threshold you remove the tile. Simplz
-
OK, my idea isn't going to work because as you travel along the dirt is removed with jagged edges and rounded corners:
[EDIT] Oops, that's a bit large!
-
Use two layers back layer totally filled dirt
Overlay a transparent screen and draw your tunnel on that screen. Looking at the edge pixels of the tunnel they repeat every 8 pixels each direction so if you want to remove dirt one pixel layer at a time you'd need eight images on the x and eight on the y or two pixels half that. Just keep track using mod to find which image to draw.
Haven't played Mr do ? For a long time looks like it's set on a grid with the fruit .so keep track of the grid in an array - uses four bits to denote open or closed directions so you can program the enemies.
Overlay your sprites over that.
Oh yeah almost forgot give you tunnel image rounded corners. -
This post is deleted! -
This post is deleted! -
Just looked at a short video on how Mr Do does this. It appears it just draws the background black where you walked (not really collision detection on the grass needed?) In that case you could probably just draw the grass of the level on an image, then draw black over that image where you have walked (not sure if you can erase part of a picture to become transparent, otherwise I'd go with that in stead of black, so the digging could reveal things that are drawn behind the image if that would be necessary).
Eventually you just draw the updated grass image to the framebuffer that gets cleared every now and again (since you don't want to 'clear()' the grass image)
#EDIT: You could almost certainly draw the grass image to the framebuffer using
renderEffect(..)to use a specific mask color on the grass image as transparent (and use a render effect not to draw that coulor [I'm not brittish] to the framebuffer) -
This post is deleted! -
🇳🇱 well I wasn't thinking on how my typo would sound 😋
-
Right, I need to put some of these ideas together and do some digging (ouch!).
-
-
@xevdev are you not clearing the screen or just creating sprites?
-
@PB____ You can actually draw in transparent or partially translucent colors, but you have to change the blend mode to
0usingsetBlend(0). With the default blend mode the colors will blend because of the transparency. So, you can have a background layer that is gradually revealed by writing transparent color to the foreground layer using render targets and blend modes. -
@Retrocade_media no I'm not the background is a solid green and stays that way no need to alter it.
The tunnel screen is transparent and I draw image one movement at a time and don't clear so you can see the trail .
The actual game you'd draw your sprites straight over the top .
When your making a game you have your map in memory and what you display is on the screen is a representation of that.
In the case of this game it's set up on a grid that you cant get off so you can only turn every 16 pixels
Left right back forward
But you can go half way through a square the enemy needs to know that so the data for each square will need to allow it to only go so far .
So your data square will need to have more than a binary state
Open or closed
It will need to have both those and four directions with a number saying how far it's going in .
Or
You could Chuck the whole tunnel screen in an array for every pixel that's displayed there is a corresponding non zero number . write a getpixel that accesses that array
Only let the enemy move on the non zero area
I know which one I'd chose . -
So, I've been stuck on this for ages now! I think I need a mixture of both approaches. Currently I've got three layers 0, 1 & 2. Zero drawn first with no alpha. Right now it's just
clear(green), then a layer where I draw the 'tunnels' in black with an alpha so that once I get to that point I can do whatever edges I want and then finally the sprite layer where, guess what? the sprites are drawn.So far so good.
But I'm totally stuck on this whole business of being able to remove part of a tile and that's where the more i think about it, the more I need to consider this business of bitmasked values in the tile grid. And I also hadn't considered the prospect of the monsters needing to know if any of the tile directions are open.
-
Crikey mate, that sounds so complex. but I'm sure you'll crack it in time.
-
If you're referring to the bitmask thing then it's not as complex as it first sounds.
So, let's say that we have a playfield that consists of 10 tiles high, 10 tiles wide (in reality you'd have more than this) The simplest implementation of that is that the array stores the tile number:
tileData = [ 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 1, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ]So that's a simple playfield where maybe image 1 is a wall and image 0 is the floor. But if we need to also store which of the directions is open to sprites then we need to look into binary. We know that an 8bit binary number can be up to
11111111which in theory means that we can choose one of 256 tiles (if we include 0). But honestly, that's a LOT of tiles for an old-school game. So how about we instead limit ourselves to 16 tiles? Then we can split our number up. Now we can have 'dddd nnnn' where dddd are the directions that are "open" (U/D/L/R) and nnnn are one of 16 tiles. So1100 0001says that this grid position contains tile number 1 and can be entered from the 'UP' and 'DOWN' directions.Since we can use sprites for characters, and sprite images and animations can be entirely seperate to the tiles (using the image editor, or
uploadImage()as you wish) 16 background tiles may be enough. But what if it isn't? Well an INT isn't limited to 8 bits, just extend it to 16 bits (0 to 65535) - PLENTY of room for images and to use the additional bits for all sorts of things.SO, in summary, yeah, maybe a complex sounding subject and now I've typed it out, maybe it is, but it's very powerful and would have been perfectly normal in the days where memory was limited.
