Design Considerations
From Jig
This page serves as an ongoing list of JIG Engine design considerations. These considerations come from meetings, emails, discussions, etc. If the source of the design consideration is documented in the wiki or on the web, it should (ideally) be linked to here. As development progresses, it is assumed that each consideration will gain further documentation as to if/how it was achieved.
JIG Engine 1.0
Requirements:
- Sound utilities that are responsive and support obvious formats like .wav files.[1]
- Support for animating sprites using a sequence of frames.[1]
- The ability to choose full-screen exclusive or windowed mode.[1]
- Support for scrolling -- a default assumption that world coordinates are not equal to screen coordinates.[1]
- Mouse and Keyboard utilities that circumvent the need for Listeners. In addition, it should be explicitly documented how many keys can be detected simultaneously.[1]
- A DX-Framework-like console that can show debugging information and be used to toggle parameters.[1]
- Tutorials and a set of lecture slides (or webcast lecture) that presents a high-level overview of the engine. [1]
Considerations:
- Single/Multi thread design. The Colby engine uses two threads (one for updating the world, another for rendering). What approach should we take? Consider the note below about Aaron's experience improving his game's performance, but also consider that concurrancy issues are probably best avoided in lower-division courses.[1]
- GUI support. Aaron suggested supporting the use of swing components as students will likely be familiar with them. However, I think this has some fundamental limitations in that we may not be able to use e.g., the LWJGL as a graphics back end. This should be discussed some more. [1]
- Java 1.6 now integrates support for JOGL, and allows JOGL to be used with swing components[2]
. We should consider using JOGL over LWJGL, but should also explore the implications with Windows Vista, although some indications are that it will work[3] .
- Aaron suggested that there should be some support for helping seperate rendering and intelligence. This was based on an observation that his game had a big performance improvement when he took the higher-level reasoning out of the display/rendering thread and into its own thread. [1]
Design Ideas:
- Design for overall responsiveness -- the engine should easily be capable of producing quality games [1]
- Focus on flexibility and robustness not breadth -- both students suggested that it was better to keep the engine simple as opposed to trying to do too much[1]
- ↑ 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 March 19 Minutes
- ↑ Java2D/JOGL Integration
- ↑ JOGL Work on Vista
