Nearly completable…

August 13, 2009

As the title says, I think I am only one feature away from the game being completable… Or at least in theory, because there will inevitably be some unpredictable bugs. 🙂

This feature is item handling, which eluded implementation last week because dialogues took a bit more than I had hoped for. However, everything is set for it (and I primarily mean that item scripts should already run properly) and it shouldn’t be too hard. I hope to do this (and related bug fixes) in the next day or two so I can finish documenting stuff that I haven’t already before the pencils down.

A brief summary of the past week, without boring you all down in technicalities, is that dialogues should now work completely. This alone enabled many other features, like the whole intro animation working (bar palette fading for one of the effects), many subtle and not-so-subtle conditional effects that happen only during a dialogue with someone and so on. I also added correct item title placement, proper support for font colours (they’re working perfectly now), moving the dragon to the correct place when using/looking at items, running use scripts for rooms themselves (this is apparently needed at some points), support for exiting some rooms when ESC is pressed (used to stop the intro and some other places), changing the cursor when different objects are pointed at, etc. One other feature that I added, and that I feel has added a lot to playability, is the ability to click anywhere in the room with the engine then selecting the nearest walkable point and moving the dragon to it. This means you don’t have to go around hunting walking map pixels anymore.

There was also a pretty big redesign of the main loop which made it callable only two levels deep (the first level for the main interactivity, the second handling intermediate states like talking, waiting for an animation to end, etc.) This fixes many bugs which were able to crash the engine or put it in a strange, forbidden state. I also enabled evaluating small GPL math expressions which result in a single zero/non-zero value which are used in many places to check whether an object can be used, a dialogue option is available or similar. On top of all this, there were many bug fixes, as usual. 🙂

I think this covers the majority of the changes. My sleep pattern is totally borked right now (this happens to me over the summer with almost impeccable certainty) and I slept for almost sixteen hours today, trying to come to terms with sleep deprivation, so I anticipate a productive night of coding.

Good night!


Just a good old regular update

August 4, 2009

My work for this week was mainly concentrated on the main game loop and the bytecode interpreter.

When implementing other parts of the engine, I tried following specifications and implementing the correct semantics, and not just transliterating the source code from the original engine. The main loop is much trickier to get right, however, as it is supposed to be re-entrant (luckily, only two levels deep) since some GPL commands expect to be able to call it to provide for interactivity while they execute (for instance, when playing animations). The original engine uses two loop status variables to distinguish between the various states of the loop and whether the current instance is a top-level loop or a nested one. It was my decision to mirror the original code for the loop much more closely because of that. (After GSOC, I’ll look into writing some unit tests for the engine and then try to refactor away some of the nastiness in the design without completely breaking everything. Wish me luck on that.)

Besides loop statuses, I also had to implement animation callbacks because the engine relies on the animations themselves to signal the nested loop to exit after they had played to the end. Several crucial GPL commands were also implemented (along with some library/API refactoring to accommodate those). And of course, lots of bug fixes, some of them crucial for correct game logic. 🙂

The result of this work is that the game now starts “naturally” after the intro has played, characters can talk, rooms can be switched by clicking on exits and the game is interactive during animations. It also made headway for the things I’m going to do this week, which leads us to…

This week I’ll be concentrating my efforts on smoothing out some of the rough edges in the current code; some annoying, others more serious. The annoying ones are mostly minor bugs (like incorrect font colour in dialogues and incorrect placement of text), but hey, those have to be fixed too! The other, more serious, bug is that the main game loop can currently get called recursively more than two times if you click on things too many times before the animations have played through. This is the primary thing I have to fix before moving on so I can properly debug new problems as they arise.

After I’m done with that, I’ll have some fun with two other major gameplay features — item handling and dialogues. After that, we’ll have something that’s dangerously close to playable *gasp*!

Also, now that I’ve proofread the post, I can see that I’ve neglected to mention one thing: Robert and I agreed that I should probably leave proper walking with the dragon alone for now as it’s not critical for the game to work and the original implementation is a bit convoluted. I’ll get back to it once I’m done with the more important stuff listed above.

Stay tuned!

Half past 7

July 27, 2009

That’s what the time is over here. And I don’t mean PM. Nor do I ever wake up this early (yes, I’m one of those people who rarely see morning). Don’t you just hate it when “Okay, I’ll just implement this trivial feature, for which my mighty libraries are fully prepared for, by adding this line over here” turns into a mad multiple-hour bug hunting spree? Not to mention the joy I then experienced when I realised I haven’t yet blogged this week.

There. I feel much better now. 🙂

And now for something completely different… I’ve implemented a number of features this week but it still felt a bit under productive all through until now. I’ve just added support for detecting the objects under the cursor and immediately afterwards a tentative mechanism for running the look and use scripts for the object. To my pleasant surprise, things happily started twisting and turning when I clicked on them and that really added to my enthusiasm. It also went a long way toward making the game feel alive (or at least having a faint pulse).

Other than that, I’ve implemented a number of GPL commands. Some of them (Release and Mark) needed yet another addition to the Animation library (I think it’s determined to haunt me forever). Others, like the objStat* family, unlocked some more dormant functionality. I’ve also finished handling the room perspective and all other scaling in the game, so the animations now support all kinds of size trickery. This means the NoSense logo at the beginning now works. Some of the “minor” things include lots of bug fixes and handling of multi-line text.

There is also one other feature I have hacked a prototype for in Python but that hasn’t yet made it to my branch; yes, you guessed it—pathfinding! The original engine seems to use some kind of a modified version of A* but there’s a lot of global-variable callbacky fun to be had there so I’m still trying to decipher some of the finer details (which I’ll discuss with Robert when I catch him online). My Python A*-ish simulation of the algorithm seems to be working fine but it’s undoubtedly going to be a pain integrating it.

As for other future plans, tomorrow is the day I’ll add support for the NewRoom GPL command so I can walk between rooms and start work on dialogues/talking. There are also some other commands that are crying for implementation and many bugs I’ve uncovered by enabling using and looking at objects, so I’ll have my way with those.

Until next time!

Stumbling blocks…

July 18, 2009

This is just a quick update about the current progress to satisfy the one-post-per-week requirement but I’ll have another more elaborate post in a few days. Hopefully by then I’ll have a more featureful main loop than now.

The feature I was mostly occupied with during the last few days—and that turned out to be unexpectedly complicated (nothing major but many slight annoyances)—are walking maps. My plan to quickly implement that and move on failed spectacularly. 🙂 The maps are stored in a slightly weird bitmap format so obscure bugs were abound. Of course, once I actually added them successfully a whole other set of subtle animation bugs was exposed (the lack of relative coordinate support being one of them :D) so that also took quite a while. However, I’m proud to say the dragon animation can now be moved around the room correctly. Yay!

Naturally, life would be too easy if this was to be the end of my troubles. I realised shortly afterwards that there were some 6-byte Pascal reals stored in the data files (and very vital ones at that, if I want to implement scaling the dragon properly). This means I had to decipher their format; a task I’ve tackled successfully… I think. I have implemented a Python prototype of the converter and it seems to work fine. This means I’ll add scaling next and then move on to making the dragon walk from location to location itself (this means pathfinding and it makes me shiver).

I think that’s it for now. Getting back to coding!

The seventh week

July 12, 2009

I’m a bit overdue with my blog post because of some personal problems but now I’m back and thought I would give you a short update on how things are going.

Since the last time I wrote, I finished implementing the game’s animations, dealt with a number of GPL interpreter features—the math evaluator is now almost completely working and I’ve started implementing GPL commands and functions—and worked on connecting it all so I can start loading scenes. The results were much better than I had anticipated; so much that, after fixing some minor graphical and logical glitches, I was able to load all the game’s scenes and animate them properly. I have made a short demo inside the engine which lets you switch between those by clicking the mouse buttons. I will post a video shortly (after YouTube has finished processing it).

The next few things that need to be done are handling the dragon’s animations properly, adding basic interactivity and gradually finish the GPL interpreter. This also means the progress in adding new functionality should be pretty rapid.

I’ll keep you posted.

UPDATE: Here’s a link to the video I promised.

Starting the “real” work

July 2, 2009

Hi everyone,

As the title indicates, I’m nearly finished with all the preparations that were needed before I could start working on actually running the game. I already have support for most of the necessary subsystems, animations excluded, but that will be done today. It can be inferred from the schedule in my last post that this means I’m a bit behind. This is because I decided to do an architectural change concerning the representation of drawable objects that held me back a bit more than I expected. Nevertheless, today is a good day for deadline chasing!

I would say that the objective for this week would be to have an initial location loaded and make as much of it work as possible. That will enable me to test out all the code I’ve written so far as a whole instead of only through unit tests and enable me to implement a good number of the game’s script (GPL) instructions.

Robert and I have agreed that in the beginning I should probably make the following simplifications:

  • Not run any animations (or at least no complex ones that do looping and similar)
  • Not scale the dragon but just draw it 1:1
  • Make the dragon instantly move to the location of the mouse click
  • Not implement MIDI and music (this I already decided to do at the end)

This will be a good starting point that will enable me to actually see some graphical progress without trying to do it all at once and most certainly opening a big can of worms. These features can then be enabled one by one without significant effort.

On a somewhat shorter scale, today I expect to be finished with a preliminary version of the Animation class, drawing a scene on the screen and some GPL work. The Animation class will have a DrawableList (or similar) which will keep its objects (Texts and Sprites) sorted by the Z coordinate. This should make drawing things in the correct order quite easy.

Enough talk, I’m off coding. 🙂

Up till now… Hopefully Shatner won’t sue

June 24, 2009

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.