skell wrote:
agaricus5 wrote:
I don't know anything about flash, but would it be too challenging to start creating a new DROD engine from scratch if the current one is too difficult to decipher? What would be the major obstacles in attempting to port DROD to flash, bearing in mind that we'd only need a pared-down version but reasonable to good graphics?
I am not sure if the current code is bad or not, but it is different from code I write, but keep in mind I have zero team coding experience 
.
Heh. As long as someone can take over from you when you're done (i.e. we don't have a truck factor of zero), I'm pretty sure that's not exactly a problem!
Making the game is the easier part. The problem is - what kind of game we want to make. A direct port? Of AE, JTRH, TCB? Or something else? Should it be able to connect to CaravelNet? Editor? Importing Holds? And so on.
If that's the case, then I think we should begin immediately.
I personally think that the best idea would be to make more of fan-game than official-port. I can't explain why though, I just feel like it.
In this case, we could probably blur the lines between official port and fan game. It
will technically be a fan game (you're a fan, are you not?
), but it should at the very least be able to do what DROD currently can do right now, thus making it a port.
Your best bet is probably to try to port DROD 1.6, but without the level editor (if anyone wants to make levels, they might as well download DROD). Graphics should only be low priority for now; there's no point having a game that looks good that you can't actually play!
Most importantly, the game (with my limited understanding of programming) should consist of:
The game engine (this calculates everything);
Game object data store (this stores all the monster and object behaviour data), but not scripting/characters;
Room handling (can import holds and convert them to your format);
Input interfaces (keyboard and mouse control);
Visual interface (converts room data to a grid we can see using a tile template);
Browser interface (it's a flash game, right?
).
I would recommend making the game object store (i.e. the database of monster behaviour) modular, so you can simply add new monsters later on rather than having to rewrite the code from scratch each time you update. As NiroZ suggests, we should probably start with only a few elements and add more later on once the core program is working. It might also be a good idea (if it is possible) to construct the visual interface so that you can modify the tile size and it is easy to change the picture tiles you are going to use.
Less important things you might consider once you have the core working might be:
Connectivity to the Hints and Solutions board (i.e. click to go to the hint thread page immediately);
Movement clock;
Other aids (e.g. mouse-over elements, click square for coordinates, click decoy for radius);
Key remapping/support for unusual keyboard layouts;
Sound/music;
Higher quality graphics;
Scripting from JtRH and TCB;
Demo support;
Space for advertising.
I think an editor and CaravelNet connectivity would be pretty low down on the priority list, particularly as CaravelNet is currently subscriber-only.
____________________________
Resident Medic/Mycologist
/dy
.
