We (ScummVM GSOC students) have been asked to submit a status report on our progress so far and a timeline for future development. Hence the cheesy title. We have also been asked to share the reports on our blogs with the world so everyone can get the same enjoyment from reading them as they did. ? Here it is:
Already done
Prior to the first week, I’ve implemented a barebones engine/game detection as the initial patch.
[week 1]
Studied the archive formats and implemented the BAR archiver (without DFW support). The archiver supports on-demand file loading and releasing individual files from the archive.
[week 2]
Completed the GPL disassembler which will be used as the infrastructure for the GPL bytecode interpreter.
[week 3]
Added support for the original game fonts via a Font class. Added support for the DFW file format (used for archiving the mouse cursors and icons). Bug fixes in the handling of mathematical expression inside the GPL bytecode. Also, started playing with graphics by animating a few frames of the dragon as a demo on engine start. Added rudimentary mouse support in the demo (only displaying a cursor and moving it around).
[week 4]
Started real work on the graphical subsystem by implementing the following classes:
- Sprite – the name is pretty self-explanatory, but a class to manage individual sprites, including automated transforming from the column-wise format that they are stored in the original game files
- Screen – for manipulating the contents and features of the screen (like handling the palette, updating, buffering, clearing, drawing basic shapes, etc). The class also supports updating only dirty rects instead of the whole screen. It depends on…
- Surface – A class for storing a graphical surface. It manages its own dirtiness and has support for changing the current transparent colour, etc.
Unfortunately, a good deal of my time during the first few weeks was taken by unexpected university obligations so they haven’t been as productive as I had hoped. However, examining the original schedule from my proposal, I am not much behind it, except for maybe a few items (proper mouse support, start work on loading scenes and implementing parts of the GUI). One of the things I have done but had not planned to do it in this part is documenting the code properly (this was originally scheduled for the end) so that will buy me some time in case things go awfully wrong. Also, as stated in the proposal, the last two weeks were deliberately left half-empty to allow for significant risk mitigation.
Yet to be done
[week 5]
Implement a Mouse class to properly handle the mouse. Start tracking game-related state inside a Game class so we can actually do something game-related. Also, start working on drawing some initial scenes. Start working on support for animations.
[week 6]
Start connecting everything together, i.e. implement callbacks for the GPL interpreter (at least partially), loading the initial scene, running the startup GPL scripts. Continue work on animations as there will probably be a good amount of work needed for this (the game scales the dragon heavily and has support for stuff like reflection of sprites in mirrors, etc; also work on walking with the dragon). I expect this week to be particularly productive due to a favourable personal schedule.
[week 7]
Continue implementing the GPL callbacks (work on items, dialog, etc). Try to make the first few scenes work.
[weeks 8-9]
Incremental updates to the interpreter and the rest of the gameplay, gradually making more and more of the game work. My approach will be to test the parts of the game that are working, identifying the areas that are not and then implementing them.
[weeks 10-11]
Implement music/MIDI support and saving/loading the game.
[week 12]
Test the game thoroughly. Fix bugs. Anything else that needs to be done before release.
I do not view this schedule as set in stone but it will serve as a good guideline. There are probably some parts of the schedule that are too atomic, whether it’s because I cannot predict some parts of the development process completely accurately or because I needed concrete goals for each week instead of just saying “working on everything that needs to be done for the next feature/scene”. Such parts will be spread out and not necessarily done at once. The goal is to find a balance between atomicity and an incremental approach.