DRL > Requests For Features
General Progress Tracking -- Revisited
Anticheese:
Quoting: Kornel Kisielewicz
Not yet, but they are planned for this release. To do them tough, I will need to make each monster drop a distinct corpse-tile :/
Another way to do it is to have a number of variables that track what died and where.
I.E Corpse1 = Former Human (16,24)
Kornel Kisielewicz:
Quoting: AnticheeseAnother way to do it is to have a number of variables that track what died and where.
This is an ugly "hack" solution. I would prefer to keep away from those :/
STL:
Don't tell me you are keeping track of everything by their apperance!
Correct (meaning less hassle & easy to implement , maintain and extend) solution is to have logical data separate from the visual one.
If you have them separate, then it should be no problem to add a some new entities in your datastructure, even if thats an int array. Assuming the Pascal version/clone? you are using is object oriented (i.e. derived from Object Pascal), it'd be 10 minutes of coding.
If first sentence actually describes what you are doing right now, or even if it des not, I believe I can help you with general desing and other theoretical aspects of your game. If interested, let me know, so that I can give you an e-mail address that I check more frequently.
Anticheese:
Kornel has a sound reason for using corpses tailored to the species of demon, By doing this the Arch-Vile can pick the nearest (non arch-vile) corpse and ressurect it without much difficulty.
Kornel Kisielewicz:
Quoting: STLDon't tell me you are keeping track of everything by their apperance!
No, corpses are handeled exactly the same as normal terrain, that it they are referances to a tileset table.
Quoting: STLAssuming the Pascal version/clone? you are using is object oriented (i.e. derived from Object Pascal), it'd be 10 minutes of coding.
The problem with DoomRL is the fact that it is a hybrid -- it was origianly built as a procedural program, then many parts were converted to OOP. The monsters, items etc, are OOP, but the terrain features are indexes to an feature array. Paradoxicaly this *IS* the best approach, only it could be implemented better :). Some rewrites to the code would be useful, but are not a priority (and priority rewrites would be the Vision, AI and DunGen code anyway).
Quoting: STLIf first sentence actually describes what you are doing right now, or even if it des not, I believe I can help you with general desing and other theoretical aspects of your game. If interested, let me know, so that I can give you an e-mail address that I check more frequently.
I've written four semi-complete roguelike games, and designed/prototyped and thrown away many, many more -- believe me, I know what I'm doing :).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version