From Hero of Allacrost
Items on this tasklist should probably only be added by myself (Roots). It is a list of things that I am working on currently, along with a brief status report so other people know how far I am in development of each task. I try to keep this list ordered so that my higher priority tasks are at the top, and my lower priority tasks are at the bottom.
Priority level: this code is currently my top priority.
Completion status: very difficult to estimate, but I'd say maybe 50%.
Map mode is one of the most important game modes in Allacrost, and also one of the most complex. One of the most frusterating things about development for map mode is that it is dependant on so many other pieces of code. Currently, the map editor and data & scripting engine are holding me up slightly, but those issues are being worked on by gorzuate and Zorbfish.
Of the sub-actions listed below, my top priorities are sprite action processing, pathfinding, and advanced dialogue support. Event processing and context implementation are dependant on code from the data & scripting engine and the map editor that is not ready yet.
Sprite Action Processing
The way sprites "live" on maps is by processing and looping through a vector of actions. An action consists of things like "move from point A to point B". Some actions exist on both the C++ and Lua side, that is, Lua specifies point A and point B, and C++ code determines the path to those two points. Other actions are executed inside Lua scripts.
The basic mechanisms of action processing already exist and are functional as of February 26th 2006. More advanced processing still needs to be designed, and will require more support on the Lua side for it to be implemented and tested.
Path finding is implemented with the A* algorithm. A basic implementation was committed on February 26th, 2006. However, the implementation is not optimal (in fact it's quite messy) and needs to account for more conditions, like finding sub-paths when an existing path becomes blocked. Better pathfinding is a high item on my priority list, but still needs support on the Lua side.
Advanced Dialogue Support
Dialogues in map mode are actually quite tricky. We want them to be very flexible and have multiple participants in a single conversation. Currently basic dialogue between two sprites is supported. The following features need to be implemented and tested:
- Dialogue between more than two sprites - Defining sprite actions and events after every line in a conversation - Display of character names and/or portraits in dialogues - Dialogue menu and text layout needs to be improved
Implementing these features is what I am currently planning to focus on.
Map Event Processing
Maps contain a series of events that can be triggered in different ways. Discussion has lead me to a good design of the way in which events will be processed, however I first need a map (read: Lua file) that has events so I can implement and test this code.
Map Context Implementation
A map context is how we determine what tiles and sprites to show on the screen. For example when walking inside a house, I expect the house tiles to change to represent the inside of the house, and I expect the sprites on the inside of the house to now be drawn and the sprites on the outside to disappear. There is a lot of active discussion going on about map contexts and the design still needs to be ironed out.
Once I have a tileset more suitable for context (the Harrvah town tileset), I'll be able to get cracking on this code. For the time being however, I am simply drafting up ideas and design considerations.
Map mode still needs to be heavily documented. I'm probably going to write the documentation as I write the code (even though I risk having to re-write some documentation), simply because MapMode is getting so complex that even I have difficulty understanding what it does sometimes. This is a medium priority for me and I will continue documenting this code as I write it.
Audio Engine Development
Priority level: I have temporarily placed development of this code on hold.
Completion status: completion of this code is around 30% or so.
The audio engine was recently (December 2005) re-written to use OpenAL instead of SDL_mixer as it's back-end. The engine is currently capable of basic operations with both sound (WAV) and music (OGG), including playing, pausing, and stopping. Several more advanced features are planned to be included in the future, which are listed in the proceeding sub-sections as well as the audio engine documentation.
OpenAL development is at an awkward stage right now, with version 1.1 available for Windows, 1.0 for OS X, and 0.8 for Linux. This makes development of this audio engine very complicated for me as I am designing the engine for version 1.1. Currently no code is in need of more than these basic features so I have ceased development for the time being. If you require further development of this engine, let me know.
Music and Sound Seeking
Better Error Checking
Audio State Retrieval
Streaming Sound Soucres
Custom Music Playback Looping
Automatic Sound Attenuation
Priority level: story writting is currently a medium-low priority for me, but it is something that I am slowly continuing to progress on.
Completion status: totally unknown, since I have no idea how long the story will be at this point.
This section includes any work related to the story of Allacrost. In other words, the written narrative that Allacrost (the game) follows as a guide. I am currently the only writer on the team, although we may want to think about finding an editor in the future.
The prologue needs some slight brushing up. I noticed a few typos when I read it through back in December 2005 that need to be fixed. I also need to change the title page, as I discovered after talking to another writer that I should be the author, and that Tim should be the editor (currently he listed himself as the writer, and myself as the "story"). I also think it could be made to look more professional, perhaps by designing a custom template for text editing.
The first draft of chapter 01 is about 75-80% complete and is already available for staff review. I should finish the chapter in another couple of weeks, and then I'll either edit it myself, or we'll have to find another editor.
I haven't even started brainstorming for this chapter yet. I will begin drafting up some ideas after I have finish the draft of chapter 1.
Priority level: low priority, but documentation I plan to do soon.
Completion status: around 80-90%
The settings engine is really just a container for a bunch of miscellaneous information related to the game's running state. Most of it is complete, and earlier this year (2006) it was modified to manage global timing information for the game.
The settings engine is also responsible for maintaining which language the game is running in. This should be incredibly trivial to implement and just manages the proper two character language identifier. Still, we need unicode Lua files and support to test whether this works or not, so it's on hold.
Documentation should be completed within a few weeks if I find the time.
Priority level: low priority.
Completion status: approximately 80%
The input engine manages all keyboard and joystick/gamepad input from the user. It is the glue that tells the game what the user wishes to do essentially. Both keyboard and gamepad input have been confirmed to be working in the game, but configuration of key/button mappings remains to be done. Other than that, the input engine should pretty much be considered complete at this point.
Keyboard Mapping Support
Support needs to be added to allow the user to create custom key map configurations and save those in the form of Lua files. This requires a minimal amount of data & scripting engine support, most of which is probably already there. The actual modes that can re-map the keys include boot mode and menu mode, so work on this support is pending until one of those two modes are ready for it. We also need to test that unicode keyboards work as well, and perhaps provide different default mappings based on the type of keyboard detected.
Joystick Mapping Support
Currently there is no support for mapping buttons on joysticks either. If the game detects a joystick/gamepad is available for input, it automatically creates a mapping of the device, which may be unknown to the user. Work on this code is a low priority, however, since there are more urgent tasks at hand. I'll also need to have many testers with different joysticks give me feedback to fully test this feature.
Basic documentation has been added recently. This documentation is all the API user needs to know to use this engine component, but documentation explaining how this engine component works needs to be added in the future.
Mode Management Engine
Priority level: low priority, but documentation I hope to write very soon.
Completion status: about 95%
The mode management engine is pretty much complete at this point. I still need to do some minor things, like allow for a maximum of three map modes on the game stack at any time. I also need to add support so that game mode switching/loading is done in more than one thread, so that the "fade out" process of one game mode can be used to hide the latency of game mode loading for the next.
Documentation on both the ModeManager singleton and GameMode class implementation should be completed soon, as long as I don't get busy with other things.
Priority level: low to medium priority
Completion status: 70% perhaps? It's difficult to estimate
This includes all the code found in main.cpp. Command-line option processing needs work, and this also has to be made compatible with Windows (via cygwin maybe). Some of the command-line options I'd like to add include things useful for developers, such as disabling the audio engine and arbitarily loading up a specific game mode or test map.
Priority level: very low
Completion status: 99%
I consider work on this game mode to be pretty much complete now. The only changes I may make are regarding what happens to audio when this mode is entered (does it pause as well, or lower in volume, or what?). I still need to write the documentation for this class, but it's really trivial and thus at the bottom of my priorities.
Priority level: very low
Completion status: 99%
QuitMode is very similar to PauseMode, with the only difference being there is a menu for the user to confirm if they really want to quit the game or go back to the boot screen. This class too, I consider complete. Documentation has yet to be written, but is not of critical importance.
If you need me to work on something or make changes/improvements to existing code or other things that I have done, please add an entry here.