Another boulderdash inspired game....

Everything about the modern clones and remakes.

Moderator: Admin

Post Reply
Greatflash
Member
Posts: 3
Joined: Wed Nov 05, 2014 1:21 pm
Location: Norwich
Contact:

Another boulderdash inspired game....

Post by Greatflash »

Ok. Recently I decided to move from bespoke engines to the delights (and frustrations) of Unity. In doing so, the first thing I decided to use as a learning vehicle was a remake of one of my old Psion3a games called 'Balders'.

http://greatflash.co.uk/index.php?topic=471.0 (Link to original)

This was in turn a partial version of Boulder Dash.

So, all is working in unity with a full editor built in and support for mobile as well as desktop.

The game works a little different than most Boulder Dash clones in that all objects move in pixels rather than blocks. This includes our titular hero 'Balders'. The other difference is that Balders does not need to wait for a cave refresh until he can move, he can do so at any time.

The game has both Boulder Dash I & II built in. This was not because I intended to emulate or remake Boulder Dash, but I had gone so far that it seemed silly not to. These all work perfectly (except - see below) and permeability is working fine as well. I have also added Arno's Dash 1 into the mix for testing. (You can create individual levels and then combine them into a single Game Set for distribution and sharing).

Any hoo...

I have a couple of problems (will post about the others if I cannot fix them). The first being the Amoeba growth. We see this defined as two rates. Normal with a 4/128 chance and fast with a 4/16. I have equivocated them to 1/16 and 1/4. So a rand from 0-15 if a 0 is returned - grow an Amoeba.
But, my Amoeba does not grow the same as in boulder dash? It appears much slower?
The cave is scanned at precise times (the time it takes for an object to pixel move one tile - they all move together). If an Amoeba is found during the scan, a check to see if it can move is made.

The code works like this...

Find out if it is allowed to grow and also get a random direction to grow in.

Code: Select all

		bool grow = Random.Range(0, (m_blobStatus == TileObjectStatus.TILE_OBJECT_STATUS_NORMAL ? Globals.BLOB_SLOW_RANGE : Globals.BLOB_FAST_RANGE )) == 0;

		Global_Direction dir = (Global_Direction)Random.Range(1,5);
Directions are 1-4 (the rand finds a number in that range, ie. 1 to 5-1)

We then do this on each possible direction,

Code: Select all

		if (y+1 >= Globals.LEVEL_MAP_SIZE.y)		trapCount++;				// up
		else if (TileMap.GetTileStatus(x,y+1) != TileStatus.TILE_STATUS_RESERVED)
		{	
			tileType = TileMapData.TileScript[x,y+1].GetTileType();
			if ((tileType != TileType.TILETYPE_NONE && tileType != TileType.TILETYPE_DIRT) || TileMap.GetTileStatus(x,y+1) == TileStatus.TILE_STATUS_PLAYER || TileMap.GetTileStatus(x,y+1) == TileStatus.TILE_STATUS_MIDMOVE)
				trapCount ++;
			else if (grow && dir == Global_Direction.DIRECTION_UP)
				TileMapData.TileScript[x,y+1].SetTileAsset(x,y+1, TilesById.ID_BLOB, TileAnimType.TILE_ANIM_TYPE_GENERATE_GLOBAL, TileStatus.TILE_STATUS_RESERVED, TileStatus.TILE_STATUS_RESERVED, false, false, Global_Direction.DIRECTION_NONE, new Vector2  (x,y));
		}
[/code]

It first checks if it is trapped (ie. cannot move in any direction, and increments a trap counter, 4 = totally trapped). If totally trapped, the returned value (being 4) adds 1 to a counter, if the counter = number of amoeba, then they turn to diamonds. This works.
If the number of amoeba >= 200 (can be changed per level) then it turns to rocks. This works.

So, with the Amoeba, I have the one problem mentioned above. I really don't know how to fix it?
In the original, the cave scan is after a delay (cave speed) and should be doing the same as my code. My code (because the game is intended to be silky smooth at all cave speeds) moves in pixels as part of a tile. ie. if the tile is 60 pixels square, the amount of moves at speed 5 (default) is 60/5 = 12. So, for ever 12 updates of the code, the cave scan is called and the amoebas will move (if the random number is in their favour and the given direction is free). As far as I can see, this is the same as the original. but.. take a default speed in the original, ie. a delay of 8. This would mean 8 updates per cave scan, mine is (default) every 12 scans. This should not make any difference as the movement is the same. BD's 8 is the same as my 12 in as much as an object moves the same distance.

Any help would be really appreciated as this is driving me nuts. It wasn't my intention to replicate BD initially, but it would be nice.

Everything else is working fine except a couple of minor niggles that I will perhaps post later. (and will have to set up some image sharing so I can post some pictures).
Greatflash
Member
Posts: 3
Joined: Wed Nov 05, 2014 1:21 pm
Location: Norwich
Contact:

Post by Greatflash »

Still thinking about this... lol..

The lower the delay, the more often the cave scan is called.

So, looking at my delays (and these all have to be a division of the tile size, somewhat limiting my choices).

The tile size is 60 pixels. So, this allows for (reasonably in a 60fps update) delays of

5, 6, 10, 15, 20. (which equate to pixel movements per frame of 12, 10, 6, 5, 3).
The delay of 15 appears pretty close to the speed of a default level 1 cave in BD. Though the delay there is 12 i believe.
In BoulderDash I, the speed of the cave is not set on a cave-by-cave basis as it is in the Construction Kit. Instead, the speed of play remains the same for any given level of difficulty, but increases with level of difficulty.
The speed of play is implemented with a delay loop. Each frame, if the CaveDelay is greater than zero, BoulderDash enters a time-delay loop for 90 cycles per unit of CaveDelay (remembering that the C64 runs at 1 MHz). The actual number of frames per second will vary depending on the objects in the cave; a cave full of boulders takes longer to process than a cave full of dirt.

Difficulty 1: CaveDelay = 12 (1080 cycles)
Difficulty 2: CaveDelay = 6 (540 cycles)
Difficulty 3: CaveDelay = 3 (270 cycles)
Difficulty 4: CaveDelay = 1 (90 cycles)
Difficulty 5: CaveDelay = 0 (no delay)
[/quote]

So, a base is 10 moves per frame (60 / 6). This is pretty close to the default 12. But, it is 2 units out. This then affects the frequency of the cave scan. Also, the play feels too fast. Bearing in mind that the player moves without the random element that can make you miss a move opportunity. ie. you can always move and always push an object. So, a delay of 15 (the duration an object takes to move one tile) appears to work pretty much the same speed. Sadly, I cannot have the same scope of speeds as the C64's 0-32 (only really being able to have 5 settings).

Anyway. As I say, I am not trying to make a 100% copy of BD. Rather an approximation that enables BD levels to function and be played. Which, 90% of the time can be, and are a lot of fun too. What I did add was the ability to manually set the elements of the Amoeba in the editor. So, you can adjust, time till turbo, normal random, fast random, and max size. This does allow maps to be 'tweaked' when constructed. But does not help when using a BD1 or BD2 level. Need to find a way to alter the randomness of the Ameoba based on a conversion from the BD delays to my delays? Hmmmm...

Sorry for going on and on, I was hoping that putting it down in text would give me a brain wave - it hasn't :lol:
Greatflash
Member
Posts: 3
Joined: Wed Nov 05, 2014 1:21 pm
Location: Norwich
Contact:

Post by Greatflash »

Certainly rather quiet around these parts.
Post Reply