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.

No fancy title this time…

June 16, 2009

… because I can’t think of anything neat. Okay, I admit it, I’m really bad with titles. 😛

I’ve done some more work on the Draci Historie engine. Some of the visible new features include support for the game’s original fonts and mouse support. Some of the not-so-visible features include work on a sprite class which will be needed later on when I start incorporating actual game elements.

While I was working on mouse support, I noticed that one of the original game files was in an archive format that wasn’t BAR and it just happened to be the one that the cursor sprites were stored in. Upon further investigation, it appeared that the archive was in DFW format, an older format that was ditched from the game… or so I thought. Funnily enough, I did investigate the format of the files when I first started and, apparently, somehow missed that one file. Even Robert agreed that DFW was no longer used. Long story short, the archiver class now supports DFW files too.

In other news, I was asked to post a short video of that animation I talked about last time. I tried running it with the hq3x filter enabled and things looked really nice. I was going to post a video with the filter enabled but then I realised that I’m too afraid of potential purists going after me. So, here it is, the original, unaltered, 8-bit, Draci Historie goodness. Well, maybe a bit scaled. 😛

On dragons and bytes

June 11, 2009

In my last post, I mentioned that my next task was to implement a bytecode disassembler for the game’s scripting language (which is, humorously enough, called GPL). The disassembler is now finished, leaving ‘only’ the actual callbacks to be implemented to become a full-fledged GPL interpreter. Comparing a few disassembled scripts with the originals yielded favourable results and since I had the x86 reference implementation, I’m fairly certain I’ve got things right. 🙂

Completing the disasm also earned me my own branch in the ScummVM repository so I can finally stop juggling patch files around. There are talks on the mailing list about switching over to a DVCS so hopefully these kind of issues can be avoided altogether in the future.

Robert also did some great work in cleaning up the old source code. He translated almost all of the original identifiers from Czech to English so the code is much more readable now. My girlfriend is especially going to appreciate this as I can finally stop pestering her to translate for me (thank you, Nika :D).

Finally, I should probably live up to the “dragons” part of the title: I’ve begun dealing with the graphical subsystem of the game and, as a test, I’ve set up a short animation of the main character (who is a dragon, obviously) that plays itself on engine start. Below is a screenshot of the little guy in action. Well… Not that much action just yet. 😀

Draci Historie animation in ScummVM

Draci Historie animation in ScummVM

Coding the BAR archiver

June 2, 2009

Hi folks,

As I’ve mentioned in my previous post, I have been working on archiving code for Dračí Historie during the last week. The coding process went smoothly enough thanks to Robert’s helpful comments about the archive format; I have been able to do it almost without looking at the original code.

Before I implemented the archiver in C++, I coded a quick and dirty Python prototype to ease development and analysis of the game’s data files. Since I only need to implement those parts of the engine that are required to make the game playable, I wanted to check which features of the original archiver were used in creating the final data files. To my surprise, none of the files appeared to use compression even though the original archiver was capable of handling multiple types (including LZW and Huffman coding). After a bit of digging around, Robert confirmed that this was indeed the case. Too bad; I was looking forward to implementing a Huffman tree for something other than university assignments. 🙂

I also did a tremendously stupid thing which I would like to share since it almost cost me my entire code. During development, I kept the code in a working copy of ScummVM’s Subversion repository. When I needed to make a diff of the work, I noticed that I haven’t yet made svn keep track of the new files. I did a ‘svn add’ on the whole directory, but then I realised that it added a bunch of temporary files my editor had left there. Not really thinking it through, I did a ”svn delete’ on the whole directory, planning to readd it once I’ve deleted the superfluous files. Of course, the files had never been committed before and I forgot to use the ‘–keep-local’ option. The moment I realised what I had done, my mind painfully replayed all those stories about how ext3 files cannot be easily undeleted. Fortunately for me, a bit of googling turned up this (a very good read). Naturally, the entire incident happened moments before I wanted to send the code to the patch tracker. I have to learn to backup more often.

I was away during the last three days so I haven’t done much work during that time. The next thing on my list is to implement a basic parser/decompiler of the game’s scripting language bytecode. The original parser is written in x86 assembly so I’m expecting loads of fun with it.  I’ll also have to investigate which streams in the archives contain the bytecode.

I’ll keep you posted on that.