bilwis / rmd Goto Github PK

Preferably a flexible "generic action" approach, where specialized actions (such as "EatItem" or "OpenDoor" or even "Move") are all derived from a generic Action class, have their own (perhaps even dynamic) action cost and (see http://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/) maybe even a smart system for suggesting "sensible alternative actions" on failure.
Time and speed, even though the game will block for player input are also essential, if somewhat trivial in the simple first iteration I have in mind.

For now, let only the player target his attacks at bodyparts, let AI choose at random. Also, player can have "perfect vision" (see all Organs from any distance), but prepare to change that later. Also, work out basic item properties (weapon "impact" vs. organ resistance, perhaps). These will hopefully be much more detailed later (sharpness, mass, area, etc.; ref. Dwarf Fortress).

Actors should be assigned different implementations of an abstract AI class for certain behaviours (ex. RangedAi, CasterAi, MeleeAi etc.). For the first Alpha, a reasonably solid pathfinding and very basic attack logic should be implemented.

Preferrably by using boost::serialization into an XML file. This ensures good version control, easy extensibility and cross-platform compatibility as well as being human-readable (more than binary, at least...)

During construction of subclasses of Part (such as Organ and BodyPart), all char* parameters are copied with the following method:

char* buf = (char*)malloc(strlen(param));
buf = strcpy(param);
this->param = buf;
delete buf;

Since strlen() returns the length of a char array without the null terminator, it may be wise to use sizeof() instead or adding one(?) to the value. strcpy(), given enough memory, should copy the null terminator.

During construction of Part and its derived classes, strings are given as parameters. These are copied by allocating memory and copying the string into it. The dynamically allocated char arrays are referenced by a header-declared pointer variable, but (presumably) not automatically freed on destruction. In order to ensure memory integrity, all calls to malloc() in the constructor should be matched by calls to free() in the destructor.

Item effects, special monster attacks, scrolls. Ties into #10.

During construction of Part (and its subclasses), string (or char*) parameters are copied to the internal variable using the following method:

char* buf = (char*)malloc(strlen(param));
this->param = strcpy(buf, param);
buf = NULL;

strlen() however returns the number of characters in a char[] without the null terminator. Therefore it allocated a byte less than needed and the terminator is cropped during strcpy(). It may be wise to use sizeof() instead or add one byte to the malloc() request.

If the sum of the toes on both feet in the Body.XML is larger than eight, the program will crash during the subgraph creation phase of the BodyMap graph compiling. There does not appear to be a problem with parsing the XML itself and the internal representation of the body seems to be intact. There might be a problem with the ofstream handling or the recursive createSubgraphs function itself.

Pickable(), Stacking, Containers, Equipping etc.

Data files could be XML or JSON. Maybe implement simple scripting framework with lua or some specialized C++ scripting language.

Health points, a speed stat tied into the action system (#7) and perhaps a simple "status" for every BodyPart (fine, injured, destroyed, severed; maybe).

If possible, tied into the Actors Body state (ex. Leg severed = speed reduction, or Eyes destroyed = blind) and perhaps into simple magic items (scrolls, item stats etc.).

1. Map generation
2. Scrolling w/ player in center, (asynchronous) loading of chunks on edge passing
3. No height information necessary (no 3D!)
4. Saving seed + "delta" information (changed tiles) to file or db