The model essentially manipulates your data. This usually includes database access, but it can also include data calculations (such as business rules or, in your case, game rules). However, I see many people only use the models for database access and end up putting a lot of their data manipulation in the controllers.
The controller is the traffic cop, deciding what to do when a request comes in, which model(s) to invoke, what to send to/read from those models, which view to invoke, and what data to send to the view.
Generally, your controllers and models will always be objects -- especially if you're using a framework that depends on your controllers and models to extend base classes. Within your controller classes, you might have multiple methods which represent different specific types of requests within a general request type. In CI, for example, if your url calls "www.example.com/foo/bar/", it will invoke the bar() method within the Foo class (after invoking the constructor method if there is one).
The view could be a class, but I don't think I've seen anyone actually do that. It's usually either procedural PHP or a templating system (such as Smarty). You never invoke (or redirect to) the view directly via HTTP -- you always (normally) invoke a controller, which will then invoke the applicable view (internally probably via include() or require()), which allows the controller to make any output variables/objects available for use within the view.
So, after all that rambling, chances are Dog and User would be models: things whose data you want to track and manipulate. Your controllers might include an Action controller, which could include a feedDog() method, a walkDog() method, and so forth. Both methods might invoke the same view, but with somewhat different data that would control what sort of message is displayed to the user, while also displaying the current user and dog stats (common to any action).