Game programming without a main loop

Question

My professor gave my class an assignment today based on object oriented programming in Pygame. Basically he has said that the game that we are to create will be void of a main game loop. While I believe that it is possible to do this (and this question has stated that it is possible) I don't believe that this is required for adherence to the Object Oriented paradigm.

In a diagram that the professor gave, he showed the game initializing and as the objects were instantiated the control flow of the program would be distributed among the objects.

Basically I believe it would be possible to implement a game this way, but it would not be an ideal way nor is it required for Object Oriented adherence. Any thoughts?

EDIT: We are creating an asteroids clone, which I believe further complicates things due to the fact that it is a real time action game.

Answer 1

The professor is presumably trying to get you to code from an event-driven perspective. I'm not sure this is a requirement for object-orientation, but the two paradigms tend to fit together well.

PyGame uses an event model, but it doesn't process these events in the normal way that event-driven software usually works. The common event paradigm is that the consuming code registers with the event creating library for events it is interested in, and is then called by that library whenever those events occur. AFAIK, PyGame does not have this subscription model and instead puts events on a queue. It needs consuming code to process that queue proactively and, what's more, it needs this queue to be processed once per frame*, even if the queue is empty and there is no updated UI to draw (it uses these calls to do background processing which keeps the program ticking along).

So, depending on the game (typically one that has a static user interface until something happens - think chess, not Space Invaders), it is theoretically possible to have a game with no loop... but not if you're using PyGame which is explicitly designed so the user must implement one.

In my opinion, the best you can do (could do - I'm aware OP was over 14 years ago!) is to implement an object that executes a minimal loop executing perhaps 30 or 60 times a second and allows interested objects (possibly derived from an event-consuming base class) to subscribe to the events they are interested in.

*A specific frame rate is not prescribed, but with no other considerations, "several" times per second at minimum is probably a good assumption to make.

Answer 2

Hmm. In the general case, I think this idea is probably hokum. SDL (upon which PyGame is implemented), provides information to the program via an event queue, and consuming that queue requires some sort of repeatedly checking the queue for events, processing them, and waiting until the next event arrives.

There are some particular exceptions to this, though. You can poll the mouse and keyboard for their state without accessing the event queue. The problem with that is it still requires something like a loop, so that it happens over and over again until the game exits.

You could use pygame.time to wait on a timer instead of waiting on the event queue, and then pass control to the game objects which poll the mouse and keyboard as per above, but you are still 'looping', but bound by a timer instead of the event queue.

Instead of focusing on eliminating a main loop, how about instead think about using it in an object oriented way.

For instance, you could require a 'root' object, which actually has its own event loop, but instead of performing any action based on the incoming events, it calls a handler on several child objects. For instance when the root object recieves a pygame.event.MOUSEBUTTONDOWN event, it could search through it's children for a 'rect' attribute and determine if the event.pos attribute is inside that rect. if it is it can call a hypothetical onClick method on that child object.

Answer 3

Turn based games or anything event driven would be the route to go. In other words, take desktop GUI apps. They'll just tick (wait) over until an event is fired. The same could be done for a simple game. Take Checkers for example. Looping each game cycle would be overkill. 90% of the time the game will be static. Using some form of events (the observer design pattern would be nice here) would provide a much better solution. You're using Pygame, so there may be support for this built in, through due to my limited use I cannot comment fully. Either way, the general principles are the same.

All in all it's a pretty rubbish assignment if you ask me. If it's to teach you event driven programming, a simple GUI application would be better. Even the simplest of games us a basic game loop, which can adhere to OO principles.

Answer 4

You might look at how python utilizes signals. A decent example I found is at: http://docs.python.org/library/signal.html

Answer 5

I think it might qualify as event driven programming? Which can still be object oriented. You see this in Flash a lot.

There's a difference between a main loop in a main class. You can still have a game class initialize all of your objects, and then rely on inputs to move the game onward.

Kinda hard to say exactly without knowing the exact parameters of your assignment, the devil is in the details.