|09-03-2002, 09:21 PM||#1|
Hey everybody, I'm looking for some input on the benefits and drawbacks of using dynamic data structures for certain types of information. I'm debating whether or not I want to code out some of my tables by making them dynamic and reading in from files. I don't imagine it would be too terribly difficult to do, but I haven't decided whether or not it's worth my time. Here is a list of advantages and disadvantages that I came up with regarding dynamic data structures.
1) Much easier to create, delete or modify entries, and it can be done on the fly (no MUD restart involved).
2) Shell access is no longer required to make changes to the data.
3) Linked lists are much easier to keep track of when using recursive code.
1) It's extremely easy to corrupt the data files. I've had to back up many an area file because I screwed them up somehow.
2) In most cases, it's easier (codewise) to manipulate and utilize tables, and a LOT of code rewriting will be involved in this conversion.
3) Inexperienced or malicious implementors may be able to destroy/corrupt data.
I had at least 1 additional disadvantage, but it can't be that important, since I can't remember it right now. However, I don't consider advantage #3 to be strong, because I rarely use recursive code, and at this point, can't think of any reason to use it to manipulate the tables which I want to convert to linked lists. I also don't consider disadvantage #3 to be strong right now, because I'm the only one working on my MUD. It's sort of my little personal project for now. In the future, disadvantage #3 may become more of a concern though.
Oh, and since this is probably relevant, I own a modified RoT 1.4, and the tables that I want to convert are the commands table, race table, class table, skill table, spell table and groups table.
Any input or suggestions would be greatly appreciated. Thanks in advance.
|09-03-2002, 09:49 PM||#2|
There are a few places where 'dynamic' datastructures are appropriate. When you don't know at compile-time which variable you're going to be accessing, you've got a pretty good indicator that you should be using something dynamic since it's impossible to get any better. But if you're talking about something silly like: get_property(ch, "hp"), it is most likely to your advantage to simply throw the "hp" variable onto the character datastructure, as this prevents the typobugs that plague dynamic systems. If you need programmatic access to the variables (e.g., looping through them all, translating their values to strings), you should probably look into reflection devices for compiled datastructures.
I use a combination of the two. All variables that I need compile-time access to are static, embedded directly into the class. I allow scripts to access these variables through a meta-object interface that reflects the variable's name and value. Game-specific values are not static at all.
You are in quite a predicament because most of your game logic is likely hardcoded. It is not a bright idea to write hardcode that depends on a dynamic variable like this -- if static code needs it, why shouldn't the variable be static? You gain so little with dynamic variables (the ability to add independant new properties can easily be given to scripts, and programmatic access is available through reflection) and you lose so much (compiler-checking of your code's integrity) that it's probably not worth it unless everything that depends on the dynamic variable is dynamic as well, e.g., it's a softcoded game like LP.
|Static vs. Dynamic data structures - Similar Threads|
|Thread||Thread Starter||Forum||Replies||Last Post|
|Google trends data for MUDs||the_logos||Tavern of the Blue Hand||12||08-31-2007 02:25 AM|
|Data Tracking||Trevalen||MUD Administration||4||05-15-2006 01:37 PM|
|Data Storage System||darmir||Advanced MUD Concepts||0||03-16-2006 12:33 PM|
|Dynamic Content||Raesanos||MUD and RPG Webmasters||7||06-07-2005 09:33 PM|
|Dynamic Descriptions||Sidmouth||MUD Builders and Areas||13||09-17-2003 04:23 AM|