CS 241 Lab 5: Group Game Project: Scrolling Background

This assignment is part of the semester-long, small-groups side-project to develop a side-scrolling game which exemplifies modular design principles and good use of data structures. In this particular assignment, we'll work (as part of your three-person groups) on getting a moving, structured background to scroll by behind a simple player token.

Remember as you work that the point of the game development is to try to write in a flexible way, anticipating possible later changes in either game specifications or program structure. Try to use a structure based on interfaces, abstract classes and classes; try not to build too many assumptions into your code; and try to anticipate possible changes that might come along. Although the game itself is supposed to be motivating, the real point of the project is to provide a more realistic context in which to explore the use of modular design and data structures concepts.

Regarding data structures concepts, the ones we have identified as potentially relevant concern the use of queues for storing and handling events, the use of a queue for round-robin scheduling of drawing updates and the use of trees or tree-like structures to organize hierarchical scene elements. Look for other possible uses of concepts we discuss in lecture as you code, and try to assess how the use of such structures affects your code development process.

• as stated above, the basic idea is to get the background to scroll by behind the (stationary) player token, say from right to left (although direction or even axis of motion is one of those decisions which which might change);
• the token or figure for the "player" should be drawn in the middle of the window and can e very simple: a big red ball would be sufficient, for example;
• allow for a layered background, with several layers contained in some sort of iterable container; in fact, you should design so that the different layers seem to go by at different speeds (foremost fastest, further slowest) in order to provide an illusion of perspective;
• allow for at least three different kinds of backgrounds (presumably these would be different classes or abstract classes implementing a common interface):
  • a background (layer) which is relatively unstructured and uniform, but which might vary according to some parameter such as time (e.g., a sky that changes from blue to black as night falls);
  • a background (layer) which is formed from some fixed picture which is "stitched" together so as to make a (seamless) repeating "loop" which runs behind the game (how well the "seam" looks might be up to the contents of the picture); can you accommodate pictures of widths could be either smaller than or greater than the width of the window?
  • a layer of dynamically-generated (possibly structured) objects which need to be created and later destroyed or re-claimed (e.g., by the Java garbage collector); in other words, an (iterable) collection of objects, perhaps sorted by position, which can be drawn when they are in the scene and then "forgotten" when they pass (sufficiently) far out of the scene (in the sample picture above, these would be the buildings; you might allow for several different kinds by using an abstract class which can be extended to get specific kinds of drawings).

As you work, you might also try to think about how other game elements will be implemented, not necessarily in terms of code yet, but in terms of overall strategy. Keeping a rough idea of the whole design in your head as you work is a good way to help anticipate issues that will arise later that might have an effect on how you code the decisions you are making now.