Project Discussion and Potential Future Issues

[HenryDane]

Here lies the description of this project, as well as a discussion of problems we may face. Feel free to comment any thoughts. I'm going to discuss a lot, and please read this entire issue before making any comment.

So in order to run this on a z80, we are gonna need to compile it into z80 asm. We could do this by hand (which would be awful) or with a cross compiler, probably SDCC unless someone can find something better. This means we will have to switch to C instead of C++ because SDCC only supports C. Also, we need to change int to uint8_t where possible so as to use one byte as much as possible, and focus optimization on CPU usage because passing one byte as an argument is durastically faster then passing four. Also, double needs to be replaced with float or int when possible because SDCC does not support double. Additionally, there are going to be performance issues with most of this, so any assembly generated will probably need to be edited by hand.

Now for game artifacts. Tiles need to be converted into groups of 9 bytes, where the first is color, and the last eight describe whether the pixels are colored or no. Also, We should work out some way to help artists draw sprites like these without needing to be able to program -- a separate program would be ideal. Multi-tile graphics are also needed and recommended, and if the artist(s) wish to modify the way something looks or is drawn they are free to suggest such a change. Furthermore, we need to have cut-scenes (256 frames max), variable rate, with sound. Music should be composed with a 12 channel limit in mind, as the 3 remaining channels (of 15 total) will be needed for sound effects, which need to be designed as well. For guides composing with the sound system, look up YM2149 composing tutorial or something like that. Lastly, raster graphics such as lines and rectangles and such may not be supported by hardware. Such objects would need to be kept in a cache and rendered on each vblank period. This would be costly and I would prefer to avoid this type of graphics.

Story design also needs to be worked on. There is a very vague outline (doc/story.md) that I made. I would like to stick to this outline as much as possible (which should be very easy to do). Ideally, the script would be written before the cut-scenes are drawn, but if the artist(s) prefer to do both simultaneously (or however else suits them) they are welcome to do so.

Map design is also an issue. For each place one can visit on the map visible in the levels.hpp file, and on the warp screens, we need to have a rouge-like map, potentially with multiple rooms, for the characters to explore. Large maps are preferable, so as to build the scale of the universe, but size for size's sake wastes player time. There is no mechanic yet for pointing to maps, nor is there yet any way for dealing with multi-room maps, nor is there a predetermined map format. Currently map tiles are just an array of ints, but should probably be changed to something like

struct map_tile{
    uint8_t type;
    bool on_fire;
    bool under_water;
    bool is_portal;
}

or something similar. There currently exists something like this in main.hpp. For the sake of the map makers, there must be a program for editing, testing, and exporting maps (in a pasteable array format of some stripe). Furthermore, we do need to have some way of minimizing ram usage during runtime (at least on the 8-bit platforms), so assembly routines to do block transfers which load and unload parts of the program would be nice, but should probably be added after a workable version exists. Music will need to be buffered in some way, perhaps with hardware. For now, assume that everything will work with whatever routines are provided, and then we can hack together a solution later.

The kernel is a complicated beast. Essentially we need to be able to compile for both the Z80 machine, and also for various x86 systems without changing code. I am imagining lots of #defines. I will write most of the kernel, and will attempt some file read/write system. Currently there is a small branch of this project which contains a big header file, which will someday hopefully be connected with actual code. This kernel branch is not yet usable in any way. Soon, however, I plan to change the master branch to use the kernel only, for the game, as essentially a wrapper for sfml which transforms, through the magic of #defines into assembly when compiled with SDCC (or another compiler).

This brings to the last and biggest challenge. This is written in C++. We need it in z80 asm. SDCC takes in C and then puts out z80 asm. At some point this bridge needs to be gapped, either by translating into C or by finding a more suitable compiler.

I hope that all of these issues can be solved, and that we learn a lot (and earn a lot of CAS hours) through this project. Good luck everyone, and have fun.

[HenryDane]

So, as a conclusion, here is a to-do list:

• find a c++ compiler for z80
• make graphics for x86 versions and for z80 version
• make graphics editor for artist(s)
• make map editor
• make maps for pretty much everything
• write a story
• make cutscenes for said story
• fix data types
• finish warp interface
• add npc's
• give enemy ships interesting AI
• add mechanics for story
• add quests and quest mechanics

I think that pretty much sums it up, so as soon as you see something you want to do, go do it.

[HenryDane]

Current state of the project:

• As of ten minuites ago, this now has at least a proposed premise for the story and a WIP story.
• Z80 support will be dropped for now.
• This project needs a major rework of both its external appearances and internal workings. There needs to be serious code cleanup, not to mention a big update for the entity & NPC mechanics.
• The cartographer program needs to be updated to actually work seamlessly with the actual application.
• The actual game needs to use more textures in order to streamline the redesign process.
• The graphics will change a lot, and will most likely consume most of the time.

This project has been resurrected. I am currently working on a way to compile for Apple devices.

More soon.