OOP: entity's knowledge of the world

While writing my game in BlitzMax and using Object Oriented Programming, I was wondering about something. (I think this still goes under general discussion as the topic is a general one and not restricted to BlitzMax.)

I have defined a type tGame. In this type, I use objects of type tEntity. tGame runs the world, of which tEntity objects are a part. So, information such as the size of the world is part of tGame, and tGame tells tEntity objects to move.

My question is, in the move method of tEntity, how does tEntity know the edge of the world has been reached? (In other words, how does it get to know about the size of the world that is stored in tGame.)

I am thinking about creating a tWorld type, and using it as a singleton. Then in the move method of tEntity I could do:

If (x >= tWorld.getInstance().getWidth()) Then
   DebugLog("reached end of world")
End If

I am interested to know how others would set up this kind of structure / information flow.

I think various languages do things slightly differently, so this will inevitably be a language-specific reply, but in BlitzMax it is fairly simple to access such information directly:

SuperStrict

Type TWorld
	Global Size:Int = 42
	Global MyEntities:TList = CreateList()
End Type	

Type TEntity 
	Method SaySize()
		Print "I know the world is "+TWorld.Size+" whatevers."
	End Method
End Type

Local newEntity:TEntity = New TEntity
ListAddLast TWorld.MyEntities,newEntity

For Local currentEntity:TEntity = EachIn TWorld.MyEntities
	currentEntity.SaySize()
Next

Yes that is a possibility, using static variables (or a static function that returns the number) in TWorld, thanks.

I think I might use that approach, it's not unnecessarily complicated. And it even has 42 as an answer which is always good! ;)

If your mindset is 'tGame runs the world' then make tGame responsible for maintaining a valid configuration. tGame should inform a tEntity instance if it is about to or has exceeded a boundary.

If your mindset it 'entities should implicitly know their limits' then you're either looking at a global variable or making a call from tEntity to tGame on every update. Making a call back from tEntity to tGame is going to hit performance slightly.

I think it might be better to go with the former. If/when you have a large number of tEntity instances, there are undoubtedly some optimisations that can only be employed when approached from top-down.

Exactly as VinylPusher said. Collision is something the game object should handle, and that involves both collision between entities and with the world.

Good points... For collisions between entities I would indeed create a method in tGame. So it makes sense to do the same for collisions between entities and walls. (Making the entity even more of a puppet of tGame.)

This top-down approach I imagine could do something like this:

Type TGame
   Field fWorldWidth:Int
   Field fEntities:TList

   Method updateEntities()
      local entity:TEntity
      For entity = EachIn fEntities
         entity.update()

         If (entity.getX() >= fWorldWidth) Then
            entity.setX(fWorldWidth - 1)
            entity.informOfCollision()
         End If
      Next
   End Method
End Type

I could take it a step further and make the entities part of the world. So, TGame -> TWorld -> TEntity. TGame would call the update method of TWorld. TWorld would call the update method of the entities, and access to the width and height of the world would be a little bit easier at that point.

Definitely *not* at home in General Discussion.

Perhaps there should be a General Programming forum. Otherwise, BlitzMax Programming, but I thought OOP game structure is a general topic.

I'm sure you're right, please continue. :)

... I suppose I would store tworld data in tgame, being more or less the same thing, and then pass the tgame instance as argument to tentity function/methods or use a global tgame instance.

Just to toss another thought into the mix. Another option is to have a TBoundsChecker object which is instantiated by TGame and is given the bounds of the world at that time. It would then be called by TGame whenever you need to check bounds and check an entity/all entities depending on your needs. You can certainly end up with too many objects but sometimes having an object type which manages or checks a bunch of stuff can be useful.

Or, when you call the function that your entity's use to check their bounds, just pass int he bounds as parameters.

If the bounds don't change then can't they be retrieved from TGame and saved in a TEntity global parms which each object refers to and, if they do change, use the Observer pattern to update the values?