Nicolas Weeger wrote: >> But I'm also not sure if your ingame comment refers to selecting a >> character to play or creating a new one. For creating a new one, we could >> perhaps leave the existing mechanism there since redoing is more work. But >> making in game (map based) character selection I think would be more work >> than just doing the appropriate dialogs. > > Current creation mechanism sucks. Yes. It's bad. It's evil. > > If only because first you choose stats then class - which then uses some > stats > more than others. > > > So let's take the opportunity to rewrite the character generation mechanism.
Maybe I'll finally get around to do that in the next few weeks, given X-mas break and fact I've finished up all my home improvements. > > > > >> Question on accounts: Where do we store this information? May be a flat >> file or dbm file or something? After all, the only information associated >> with an account is the name, password, and characters for that account - >> not a lot of information here. But flat files don't work good if you have >> thousands of entries. > > Flat file seems ok for me. > Obviously, I could suggest an abstraction layer with a pluggable storage > mechanism being DB/file/..., but in C that'd be a PITA to write :) Its a different topic than this, but having such a pluggable interface would be nice. The biggest pain would be having to emulate it if a real database is not available (emulation would probably mean a flat file with fields separated by something or another) I can think of all sorts of stuff to record. And if it was stored in an SQL database, one could then do analysis. What are people really buying from the stores? What spells are characters using? Where are people killing monsters, etc. For crossfire, I was thinking something like dbm (or other native file based method) could be used, but I don't know how portable such methods are on non unix systems. But looking at that, other than fast fetching of the keys, the data for that key is all stored in one field, so the server would still need to parse that out. So doesn't gain as much as one would like. I also suspect that for most servers, the size of this file wouldn't be very large, so even parsing a flat file wouldn't be that costly. _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
