Game-first Programming for Information Systems Students
23rd to 25th
By Steve Goschnick & Sandrine Balbo
University of Melbourne, Department of Information Systems
(We presented this short paper at IE-2005, The Second Australasian Conference on Interactive Entertainment, 23-25 Nov 2005, Sydney, hosted at UTS. It is based on our joint experience teaching 2nd year IS students how to program in Java, by way of programming board games to incentivise the learning)
ABSTRACT: A significant minority of undergraduate Information Systems (IS) students require motivation in their learning of OOP languages. Basing the primary student assignment on the delivery of a working 2D board game is a solution, if it is attainable within a one-semester subject. Introducing an existing board-game class enabled us to set board-game projects, which can be completed by the vast majority of student teams. It makes the project achievable in the timeframe, encourages the reuse of software components, and lets students concentrate on design and interface issues, while satisfying the learning requirements. Just as edutainment products have managed to motivate high school students and others into learning history, geography and other subjects, we have successfully used the computer board-game genre, to educate undergraduate IS students in the intricacies of Object Oriented Programming (OOP).
Within Information Systems (IS), all students are required to learn a modern programming language. The purpose of learning an object-oriented programming (OOP) language for an IS student is not just about understanding the concepts of software development in the OO world, but also to understand the challenges that a software developer faces. Not many IS students will become software developers, but most of them will deal with software developers very closely at certain stages during their careers. The challenge that IS teachers face, is that a significant number of their IS students are not highly motivated to learn any kind of programming language. While future job titles such as Project Manager, Business Analyst and Associate Producer, do offer significant motivation for many, the here-and-now of learning the intricacies of a modern OOP language, can hold much less sway with a significant minority of IS students. The IS student body has both students who are highly motivated in learning and doing programming, and other students who simply view it as a necessary chore, to attain skills for management and other non-programming roles they aspire to. There is some difficulty in being able to bring both these cohorts of students to successful development of programming skills, within the same programming subject ranges.
2. THE CHALLENGE
The tools have never been better. Java - the OOP language we teach our IS students - typifies the modern OOP programming language: built from the ground-up as a post-web language, distributed, robust, unicode-based and with multimedia application programming interfaces (APIs), built-in. Even the freely available integrated development environments (IDEs), such as the Foundation Edition of Borland's JBuilder  and Eclipse , are highly graphical user interface (GUI) oriented, with built-in programmer-friendly debuggers. So our problem is not necessarily one of improving the tools significantly.
We decided to base the main project of the subject on the delivery of a computer game, in order to spark the necessary motivation into all student teams.
Going from an object-oriented language such as Java, to a working game of the students own making, within a single semester subject (one of four concurrent subjects), while clearly achievable for some IS students, can be an overwhelming challenge for many. So we needed to make it an attainable goal for all committed student teams. This gave rise to our need for a widely available generic game class library or game engine, one that does make it possible for all students to achieve a workable game, within the Java language. This led us to the next question: If we make the main project of a computer language subject a 2D board-game, can we supply both the generic tools, and a project assessment-feedback cycle, that enables the vast major (if not all) of the student teams to complete the project, in the short time frame?
3. ENTER - THE SG_BOARD LIBRARY
SG_Board is a generic board game class originally developed by one of the authors in the C++ programming language and reported elsewhere . It was used as the underlying mechanism for several commercial games, including Octadial (a puzzle-logic game - see Figure 1 below), various screen-savers, puzzle games and other 2D grid-based applications.
In recent times it was converted by the same author to the Java language, and has now been released as open source under the GNU GPL license, to make it widely available to both students and teachers of Java and OOP concepts.
The SG_Board library, or package in Java parlance, includes two main classes: the SG_Board class and the Tile class, together with several auxiliary classes. Figure 2 represents a small demonstration application of SG_Board, supplied with the package, but which is not a complete game. It simply shows the basic functionality or the atomic moves available in the class, in a minimal amount of code:
- The central panel represents a board with a declared number of rows and columns - 10 by 8 in this demonstration case.
- The image with a Frilled-neck lizard in front of Uluru (formerly Ayers Rock in central Australia), is an example of placing a background graphic behind the board, as its primary art-work.
- There are five tiles placed on the board at this point in time, three are rectangular and are opaque, while two are partially transparent, demonstrating how game pieces can be regular or non-regular shapes. The last tile selected by the user (typically done with the mouse), is the current tile.
- The Left, Right, Up and Down buttons demonstrate movement of a tile in a given direction, by one place.
- The GoTo move, takes the current tile, to some other position on the board, identified by board coordinates starting at [1,1] in the top right hand corner rectangle in the grid (or removed from the board via a board coordinate of [0,0]).
- The Swap move exchanges the current tile, with the previous tile (the tile that was most recently the current tile, before the latest). E.g. Simple puzzle games that swap the last two tiles clicked, are an example of the use of this method.
- The Shuffle move randomly shuffles the positions of all the tiles currently on the board.
- The game programmer can declare areas of the board that are off-limits to play. In the demonstration code the 3 squares that have the Uluru rock beneath them, have been marked 'off-limits', meaning that no tile can be placed on any of those 3 positions - i.e. functions such as Left, Right, GoTo will refuse to do so, if the destination position requested is off-limits.
The students were given three choices of game to develop, all of which could be based on an underlying grid pattern, hence capable of implementation using the SG_Board class. They were: Snakes and Ladders, Ludo and Draughts (also known as Checkers). They were given the set of playing rules for each game, to side-step the variation in rules that exist for several of these games. Each student team consisted of three team-members. There were 81 teams, with 3 students per team (some teams with 2 students).
4. WHAT WAS FOUND?
Almost all students were able to complete the project in the timeframe. Over 90 percent of our teams achieved a working game.
Figures 2, 3 and 4 represent three completed examples of the games developed by students.
Challenges to students in developing the basic interface and the interaction strategy, was similar across all three games. However, there was some variation in programming problems and their algorithm-based solutions, across the different games. All three games required a computer opponent, but there was no strategy necessary for Snakes and Ladders - the movement of both the human user and the computer opponent, were determined by the random throwing of a virtual dice.
Most student teams chose to implement a Snakes and Ladders board game. It did have the simplest functionality, but it still required a significant understanding of the problem and development of some algorithms. Moving a tile after the roll of an on-screen dice, is easily enacted using the GoTo method, however to simulate stepping through one position at a time, from left-to-right on every second row, and right-to-left on the others, required some algorithm development.
Ludo was the next most difficult. Although it was also dice-driven, there was room for development of strategy in choosing which of the tiles (up to four), the computer opponent/s should move. I.e. The computer opponent/s could also have different degrees of skill, allowing for different levels of skills in the human player.
Also, in constructing the Ludo board from the underlying generic grid, only some positions can be occupied (e.g. the legitimate path around the board). Using the off-limits method was the easiest way to enact such functionality, which all of the Ludo teams employed.
Draughts (also know as Checkers to many) was harder again, particularly with regard to the strategy employed by the computer opponent.
5. APPROPRIATE & TIMELY FEEDBACK
During the lifecycle of the project we instigated three rounds of feedback, to increase the likelihood of success. Firstly, we asked them to make preliminary user interface sketches, together with appropriate class diagrams of the envisaged classes needed, to instigate their preliminary designs, incorporating usage of the classes in the SG_Board library. This gave lecturers and tutors the chance to see whether students had understood the usage of the SG_Board library in particular, and were given correctional advice, when it was evident that a team was off-track.
For the second round of feedback (and partial assessment), the teams had to forward their detailed designs, together with the current state of their programming source code. This was designed to shock those teams who had not begun in earnest, into action - which it did. Again, in addition to some marks for progress made, they received feedback on the overall direction of their coding. This did uncover both those student teams who were struggling with fundamental concepts, and those teams which were dysfunctional. Some dysfunctional teams were mediated, while a few were allowed to split up – doing the assignment as individuals.
6. SIGNIFICANT RESULT
Students did gain significant confidence from achieving a playable board-game, with an interface of their own design, one that they could demonstrate to and interact with, associates, friends and family members. In the process, in addition to learning the Java language constructs and OOP concepts, they learned the value of code reuse, and the usefulness of game engines in helping them to focus on the novelty in the project. By and large, they also reportedly enjoyed the whole experience. The team approach allowed students with different skills to shine in areas of the project that suited their particular aptitude. [Note: There was a lesser programming assignment in the subject, which all students were also required to do individually.] Despite the diverse range in motivation levels amongst IS students to learn the intricacies of an OOP language, over 90% of the student teams did end up with a working game, many of them commercial in quality - well, the sort of game one encounters on PDAs or mobile phones. And they did it within a one-semester subject. A workable game represents a significant personal achievement, and becomes a confidence milestone for the future assignments and projects in the later years of their IS studies. As another measure of the motivation levels achieved, a request for volunteer mentors from the student body, to mentor the following year's students, received 27 willing participants (out of 220 students).
7. CONCLUSION AND DISCUSSION
As the game and edutainment industry continues to grow, more IS jobs will be available within these industries. This makes the use of game development as an OOP language teaching exercise, doubly beneficial: in learning something of OOP languages; and in learning something of the processes of a team completing a game, albeit a relatively simple one.
In other fields of teaching we have seen edutainment products making an impact on motivational and learning outcomes for some period of time, for example in geography with games like Where in the World is Carmen SanDiego  and in history with games like Age of Empires . Our experience reported here, in the teaching of OOP programming to undergraduate IS students (recall our observation that a significant percentage of the IS student cohort are not highly motivated to learn any kind of programming language), indicates that the programming of games themselves, in projects which are achievable in the narrow timeframes of a subject, does benefit these students significantly.
This has proved achievable using a generic board-game class library (a game engine), and by providing early assessment and feedback during the ongoing project.
Briefly, a number of possible avenues for similar employment of board-game class libraries, such as the SG_Board package, within undergraduate IS course development follow:
- This approach using development of a board-game, was also useful in highlighting issues of interface and interaction development, since games are a genre of software where every new game wants a new look and feel, yet must also aspire to be more usable than what came before it. I.e. One could incorporate aspects of HCI (Human Computer Interaction) teaching into the same project. [Across-subject assignments are often hard to administer from the lecturers' points of view, but can be very beneficial to the students.]
- While we used the generic board game class to introduce students to the Java language and OOP concepts, we also predefined what games they would develop. The same basic tools (SG_Board package) could be well used in more innovative design subjects, where students are required to come up with their own 2D game concepts, and develop them.
- There are a few traditional problems in AI (Artificial Intelligence) that can be expressed with 2D grid-based games, which could easily be programmed by students of AI using the SG_Board package. For example the predator-prey game PENGI  - is based on a 2D grid with randomly placed ice-cubes, with a number of marauding stinging bees, all pursuing a roaming Penguin (called PENGI of course), who is able to kick ice-blocks towards the approaching bees in her self-defense. Lecturers could also set harder tasks involving the solving/playing (to empower the computer opponent) of puzzle games, such as for Octadial in Figure 1 (problematically, it is like a flattened, 8-sided rubic's cube, with a 2.4x1042 sized number of configurations, also known as a solution-space). I.e. Developing algorithms which solve the solution-space of such games, is a typical AI search/solution-space exercise.
- Since the SG_Board package is written in 100 percent standard Java and hence, transferable to other hardware platforms, it would also be useful for design and development of 2D games specifically for handheld and mobile devices - again, appealing to HCI based subjects.
- Agre, P. and Chapman, D. PENGI: An implementation of a theory of activity. In Proceedings of the Sixth National Conference on Artificial Intelligence (AAAI-87), pages 268-272, Seattle, WA, 1987.
- Cavallari, B., Hedberg, J. and Harper, B. Adventure games in education: A review. Australian Journal of Educational Technology, 8(2), 172-184, 1992.
- Eclipse: the open extensible IDE. http://www.eclipse.org/ Cited, June, 2005.
- Goschnick, S.B. An Object Lesson in OOP - A General Board Game Class. In Proceedings of the first Australian Software Developers Conference (ASD), Sydney, Australia, November 25-27, 1992.
- JBuilder: the Borland Java IDE. http://www.borland.com/downloads/download_jbuilder.html Cited, June, 2005.
- SG_Board: the Open Source Board-game Class. http://www.dis.unimelb.edu.au/staff/gosh/opensource/sg_board/index.html Cited, September 2005.
- Taylor, T. Historical Simulations and the Future of the Historical Narrative. Journal of the Association for History and Computing. Volume VI, Number 2, September 2003.
In: Proceedings of the IE2005, The Second Australasian Conference on Interactive Entertainment, 23-25 Nov 2005, Sydney, Australia.
[Interactive Entertainment Conference Site here: http://ieconference.org/ie2005/ ]