next »

[ｍａｓｏｎ]

It should be "Blue :I"

Blue
:I

[happymonster]

The colours were just examples..

I'll be using it for movement types, logic types, etc..

[happymonster]

Hurrah! I've now got the player moving around the screen with the arrow keys. He also slides nicely around corners when using diagonals so that he doesn't get stuck on walls. 

It feels a little unusual to be smoothly sliding around in a tile based movement. I've played games where the player jumps from square to square (Boulderdash, Dandy), and most games are pixel based. Even Chips Challenge only let you move in 4 directions (no diagonals), so it does feel a bit different than other games I've played. Can anyone else think of a game using this system?

[happymonster]

Here is an example of how the component system is starting to take place in the config files.

This is the tile for the player's arrow which moves diagonally up & left:

Code:

| arrow
id = 26
map_editor = yes
gfx_x = 0
gfx_y = 54
minimap_col = 110
move_type = move_one_direction
when_cannot_move = die_move
name = arrow
dx = -1
dy = -1

The move_type field shows the movement logic used - in this case it can only move in one direction (set by the dx and dy values). Then the when_cannot_move behaviour is what happens when it hits something it cannot move through - in this case it would die. This field could also be set to do other logic such as to stop moving, reverse direction, or some other behaviour.

Compare this to the player code:

Code:

| player
id = 18
gfx_x = 18
gfx_y = 72
layer = 2
whole_tile = Yes
group_id = 1
map_editor = Yes
minimap_col = 74
tile_type = player
move_type = move_player
when_cannot_move = x_or_y_move
name = Player

Here the move_player logic is used (where keyboard input can change the movement direction). When the player hits a wall it uses a different cannot_move logic - x_or_y move. This is used when the player was moving diagonally and it tries to move first in only the x dimension (using dx, and dy = 0) and if that fails then only in the y dimension (using dy, and dx = 0), before giving up.

In practical terms this lets the player slide smoothly around walls without sticking to them (bomberman has this logic too).

So, we start to get different tile behaviours that can be built up with this system already.

[happymonster]

I've now got the basics of the code in there for letting the player shoot arrows. This exposed two issues that I was already aware of, but need to address now.

The world is processed from top-left to bottom-right and movement logic, shooting logic, etc.. is applied for each tile (where appropriate) as it is processed. In practical terms this causes an issue when shooting: If the player shoots upwards then that arrow tile is not moved until the next frame. However if the player shoots downwards then that arrow will be moved later in the frame when that tile is reached in the world scanning pass. This is the case for arrows fired to the right, or diagonally left-down, or diagonally right-down.

This is not what we want to see, as each arrow should start to move at the same time irrespective of its direction.

The second issue is that our arrows are processed once they are in the world, moved, and collision tested, etc.. But what about if we are one tile away from a monster and we want to shoot it? Then we can clearly shoot and damage/kill the monster, but the tile never actually exists in the world (map data) at that point. We don't want to have another set of code for dealing with the logic for objects not yet fully spawned, and there may be many behaviours from a collision with a un-spawned object that we need to cover too (exploding a bomb, flipping a switch, etc..)

The solution I'm going with is to use a virtual map layer that is not drawn to the screen. New objects are added to this layer when the world is scanned from top-left to bottom-right. Then this layer is scanned and objects are pushed into the world by being moved from the virtual to the real layer. If there is already a tile there then we would do the normal collision detection, but directly against the two layers, rather than having to add some abstract tile object code that deals with tiles that don't actually exist in the map data.

This also solves the problem of some arrows moving too early when fired, and lets us deal with different kinds of new tile additions instead of just player fired arrows.

Hope that makes sense!

[happymonster]

[happymonster]

Once things are further down the road, I'll probably optimise the game logic to read the tiles that need to do logic code from a list rather than scanning the whole map each time.

For now, I want to add more tiles and behaviours and get a feel for how it plays as a prototype game.

[eigenbom]

Can't wait to see the smart tiles like buttons, doors, arrow shooters, enemy spawners, trapdoors, fire extinguishers, and water tiles.

[happymonster]

Fire extinguishers? 

[happymonster]

I'm not really sure about the current graphic style, but also don't know what other style to try. In the meantime I'll carry on adding features to the engine to add more tile types.

[eigenbom]

At this stage, I'd cut it right back to be as simple as possible. Having shine and drop shadow in the current tile set means that whenever you add a new thing you'll need to draw it with shine and drop shadow, which is just wasted time in these early stages. Just choose a small palette and have solid sprites and tiles for now.

And yeah, fire extinguishers to extinguish fires.

[happymonster]

Hmm.. That's a good point actually. I think I will try that and get more of the game in there with simple tiles.

Thanks!

[happymonster]

Added in collectable cash, destructible wooden walls, and pits which you can't move over but can fire over:

[eigenbom]

looks cool

[happymonster]

Cheers! 

[happymonster]

Added in chasing monsters now.

[happymonster]

Hit a slight problem.. As the game is tile based, then collisions between moving objects seems to occur too soon to the player in that your arrow will destroy a monster before it appears to touch it.

This is a bit of a limitation of having a tile based engine underneath, so I've been thinking of different ways to fix it - but not really motivated to do any of them yet!

I'll probably add more tile types and graphics while I think of the best way to tackle the problem.

[eigenbom]

How about when you detect a collision: remove the arrow and monster, then add a temporary composite (monster, arrow, and a blood patch) to the monster's previous location. The temporary object would exist on a separate layer to the normal objects. It would last a second or two and then vanish.

[happymonster]

Thanks for the suggestion, but what needs to happen is that the arrow and monster need to continue to move until they touch each other (even if they are in the same square on the map at this point). I need to work out the best way to do this, and deal with other instances where the tile based nature will cause a problem.

Working on more tiles and a quick game UI:

[happymonster]

I've added in the code to let you collect cash (which increases your score), hearts and the 4 coloured key types. Now I need to make them actually do something!