The Luwak Ludic Toolkit is an ultra-lightweight framework extending the ACM's JTF software to support game programming by beginning programmers.

Introduction

This is the homepage of the Luwak Ludic Toolkit (Luwak). Luwak is built atop the ACM JTF, providing students with the mechanics to create a real computer game with just a few lines of Java on the very first day of class.

What sets Luwak apart from other game-building toolkits is that it is built, from the ground up, to be exposed to beginning programming students. All approaches and algorithms were chosen for pedagogical transparency. On the first day, students write fifteen lines of code, using six preconstructed classes, to implement the game of Pong; by the end of CS1 students have seen the source code of every moving object on the screen, the main game loop, and even the collision handling event system.

Benefits

Luwak provides the CS1 instructor with several obvious benefits: students are motivated by writing computer games; it is based on the ACM's Java Task Force's work; the toolkit demonstrates and supports how to write good, maintainable Java code; the toolkit can be peeled back to permit students to program directly with the ACM JTF toolkit.

With declining interest in computer science, many instructors are looking for a hook to bring students into the CS1 classroom. One successful tactic has been having students build computer games. The upside of using computer games is improved engagement, greater student effort, and greater student success. The downside of using computer games is the lack of a comprehensive textbook, the time of preparing lessons, and the complexity of implementing computer games. These downsides are addressed by Simple Computer Games, the text that was developed for Luwak and the ease of use of Luwak itself.

By extending classes developed by the ACM's JTF, Luwak builds on respected, tested code. The addition of interacting on-screen objects is the focus of Luwak and that is all the toolkit does.

Luwak code is very well documented using the Task Force's tools for extracting a student's view of the documentation and a maintainer's view. The documentation explains both the design and the code used to implement it. Students see well-structured, well-documented code in a moderately large project as they learn how the toolkit works.

Finally, seeing how the toolkit works means that students, in the course of a semester, can learn how to replace Luwak with their own code. This means that they can move past needing Luwak very quickly.

Requirements

Luwak's primary requirement is Version 1.0 (or greater) of the ACM JTF's acm.jar software. The JTF software defines a Program class hierarchy of which Luwak's GameProgram is a subclass.

The Taskforce's package also defines a number of GObject (Graphics Object) based classes for drawing on the screen. Luwak uses these classes to implement the LObject hierarchy of animated objects.

Design

This is a short take on how Luwak is designed. A rationale document, similar to the one provided by the JTF is in process (target date: 2007-10-07) and this section will go the way of many things when design decisions are better documented there.

The design rationale for the Luwak Ludic Toolkit was five-fold:

  • Use unmodified ACM JTF packages.
  • The toolkit must be easy to understand (both inside and out).
  • Easy things must be easy.
  • Two-dimensional games from the Golden Age of Arcade games should be possible.
  • Some hard things might be possible.
  • All else being equal, performance matters.

These four goals are presented in decreasing order of importance. The first goal, pedagogical transparency is the over arching goal. Each new capability, sample game, or class, was first considered in light of this goal. Even performance would be sacrificed for ease of understanding (this seems like blasphemy to experienced game programmers but the pedagogical experience is paramount for Luwak).

Pedagogical transparency led directly to the use of a single-threaded physics simulation with collision handling specified by the CollisionGroups that an object belongs to. Initially, students simply define their objects to be player-controlled or game-controlled; it is assumed that player and game controlled objects interact, one with the other group. Later, students can define any number of CollisionGroups and add their objects to them. Limiting the sizes of interacting collision groups keeps performance up.

Each object can also have forces attached to it. A single Force object can interact with any number of moving objects; this permits a single GravityForce or SwarmForce to provide physical simulation for multiple objects on the screen.