Principles of interacting with different objects

[ohookins]

Hi, I'm a fairly experienced developer but fairly new to game programming and the Löve framework. I'm trying to write a fairly simple side-view game that has a character who just walks around and interacts with different things. For example, ladders should be climbable, it should be possible to pick up objects etc.

In terms of walking around and checking for collisions with walls, the floor, other objects etc that's pretty straightforward. I'm trying to figure out how to best express different ways other objects can be interacted with, different modes the character can then transition into (for example, movement while climbing a ladder is entirely different from walking along a flat surface). Both the movement/activity modes of the character are a bit hard for me to wrap my head around, as well as how to express the objects in each screen/level.

I've looked at the Tiled Map Editor which seems to cover some aspects but I'm not making a tiled game. Any other suggestions for solving the problems I've outlined? Blogs/screencasts and any other educational resources on the topic would be fantastic. If you can suggest any good technical books about game programming that would also be awesome.

[laice]

I'm not sure I completely grasp what you're asking but it sounds like states might be what you're looking for. States are good for everything from overall level management to specific actor modes. I've had good luck with kikito's Stateful library. If states are overkill then I'd just use what you can infer from collisions to change control of the player depending on context. For example, the up arrow might make the character jump except when colliding with a ladder in which case it moves them on the y axis at more of a walking speed.

Are you having trouble expressing objects graphically or logically? MiddleClass, also by kikito and required for Stateful, adds an easy, organized way to do classes which may be useful to you if your experience is in languages besides Lua. Both Stateful and MiddleClass are well documented. Also, you might get more replies if you provide code snippets or a .love with specifics of your problem.

The best way I've found to research game design is figure out what genre you want to make and read what people who make them are doing and have done, and the techniques they use. So in your case I'd be reading about platformers.

[ohookins]

Hi laice, thanks for your reply. I've already got a state-machine implementation for the player's character, which changes based on the context - e.g. if it is now colliding with a ladder it is possible to transition from the "walking" or "idle" states to "climbing_up" or "climbing_down" and then from there to "on_ladder" (effectively just not moving on the ladder). I guess I'm concerned with the generality of this, and how much it is going to blow out in terms of lines of code and complexity once many other objects come into the game.

Also, right now it relies on checking whether the player is colliding with anything on the screen and checking a property of that object (e.g. isClimbable). This may later extend to checking if the object has isPickupable or isLiftable etc... I just want to sanity check what I'm doing before I write a whole bunch of code I inevitably have to refactor.

In the meantime I'll check out Stateful and MiddleClass, they sound interesting. Thanks for the suggestions.

[Plu]

Can you show us some code on how you're handling state transitions? There are many different ways to do it.

[ohookins]

Yes, the character logic is all here at the moment:

https://github.com/ohookins/mole/blob/master/mole.lua

[Plu]

Hm, using if statements seems to be the most common solution, but I always felt they maybe weren't the cleanest way to do it. For a thingy I'm working on now I was experimenting with using movement functions that can replace themselves on state change. Maybe the concept is of interest to you. It works something like the below (which is for informational purposes only doesn't actually work.) I don't have the code here now, but if you want more info just ask.

Code: Select all

-- each input state has a table

-- this is moving on ground level
freeMovement = {
  right = function() self.x = self.x + 10 end
  left = function() self.x = self.x - 10 end

  up = function() if collision( ladder ) then return state( 'climbing' ) end
  down = function() if collision( ladder ) then return state( 'climbing' ) end
}

-- so this is for climbing ladders
ladderMovement = {
  right = function() return state ( 'freemove' ) end
  left = function() return state( 'freemove' ) end

  up = function() self.y = self.y - 10 if not collision( ladder ) then return state( 'freemove' ) end
  down = function() self.y = self.y + 10 if touching_floor() then return state( 'freemove' ) end
}

-- this function returns a movement mode based on input; a VERY basic implementation
state = function( switch ) 
  if switch == 'freemove' then
    return freeMovement
  elseif switch == 'ladder' then
    return ladderMovement
  end
end

-- loading the starting movement mode for the player
player.moveMode = freeMovement

-- movement handlers in your update function
if love.keydown( 'right' ) then f = player.moveMode.right() if f then player.moveMode = f end end
if love.keydown( 'left' ) then f = player.moveMode.left() if f then player.moveMode = f end end
if love.keydown( 'up' ) then f = player.moveMode.up() if f then player.moveMode = f end end
if love.keydown( 'down' ) then f = player.moveMode.down() if f then player.moveMode = f end end

The basic idea is that your player at any time has a moveMode object/table attached to it that handles all input based on his current state. Each of the function calls can optionally return a different moveMode object/table to signal that the player has entered a new state. This lets you define each state in a nice little block of its own, without any if statements in them.

Like I said; this is just something I was toying with so I have no idea if it's structurally sound, but it seemed to work really well in my experiment so far. Take from it what you will.

[ohookins]

Yeah, I saw something like this in a thread elsewhere and used that for my mole.draw() function (which you might have seen). I quite like that pattern so it's a good suggestion to use this also for state transitions.

Interestingly enough there's a project at my work where we've taken this very approach (although in obviously a completely different context) for a state-machine type of implementation and it seems to have been a good solution there as well.