@Keeth: I set up a structure that allows objects to be initialized on the map using a database element simply by defining its type id.
People keep missing this and assuming that you can't set up subtypes on the map. That's not the case.
I'm not assuming you can't. What you're doing is defining a database system that doesn't work with the map editor, and then writing a go-between object so the map editor will technically work with it and so you can define more hard-coded activities.
I think it's a good exercise, but if your goal is to develop games quickly and intuitively, I think this is just an extra step you can forgo, unless separating the database from the codebase is absolutely necessary for some reason I can't quite figure out. | |
I'm not separating the database from the codebase. I'm demonstrating how object oriented hierarchies are supposed to work.
You don't need 1000 nodes in the item branch to have 1000 items. You only need as many nodes as behavior requires. This approach is so little work it's hard to sympathize with anybody who argues that this is a lot of work. I'm simply setting up behavioral proxies for working with the map editor, and they work quite well. | |
At this point, I prefer setting up subtypes in code without jumping through hoops. I've never used a language that lets me override variables in child types like DM does because DM was designed a certain way that makes the separate database approach unnecessary. Plus, the map editor's instance editor is clunky from underuse. If an instance isn't on the map when you compile, it's deleted from the instances list.
The only problem I've been having with inheritance is when completely different types need to share a certain behavior. Sometimes I try composition, sometimes I end up moving everything to /atom or /atom/movable. That's a different topic, though. | |
Off topic: I was literally just talking about this yesterday with someone. At times, it just feels as if there's a necessary messiness that comes with programming in DM (something about how it's structured).
But enough feeding. | |
Kaiochao wrote:
The only problem I've been having with inheritance is when completely different types need to share a certain behavior. CTRL+C and CTRL+V, noob! | |
Magicsofa wrote:
Kaiochao wrote:  | |
Correct me if I'm wrong, but aren't all of the variables in the vars list strings?
Meaning that you need to use text values in your initialization of new item prototype variables in your example, rather than just max_dmg? | |
Nope BYOND recognizes this format as well for associative lists, if I recall.
| |
BYOND implicitly should recognize the text labels in associative list definition as strings, regardless whether they are in that format or not.
| |
It's in the documentation somewhere that list keys given in var format (letters, numbers, underscores) are automatically converted to strings, even if you have a string variable of the same name.
| |
I think I said nope when I clearly meant yes by the context of the rest of my answer.
| |
I'm currently experiencing issues with identifying if an item is in a player's contents, and therefor needs to be stacked with this item system(database?methodology?). I can provide my full pickup code but I believe these lines will be sufficient:
What worked prior to converting to this database: var/Item/X=locate(src.type) in p.contents Some lines of code someone(me) who doesn't have a clue on how to get this to work attempted This looks for an id, which is useless because it needs to find an item with the id. var/Item/X=locate(src.id) in p.contents Inherit item confuses me and so does instance, I don't have a clear understanding on how or when to call upon them. I assume Inherit is used to give items their properties or to give someone loading a savefile their items(whether these items were edited or unedited since they saved. I didn't want to fool around with new() because than I'd be physically putting the item I'm looking for in the player's contents which seems like a big no-no. Although, New() happens to be the only proc I've called upon since I transferred all my items in my project over to this database. With that said, this line below helped providing me with some runtime errors. var/Item/XI=InheritItem(src.id) I've tried other things, but like these lines(with the exception of what used to work), I doubt they'll be of help. Can someone give me a quick run through of instance() and inherititem() and/or how to address my ongoing problem? | |
I'm not completely sure of the context, but this kind of thing is pretty easy:
proc/get_item_by_id(id, items[]) | |
This looks exactly like what I was looking for. I may have been able to found the solution eventually but man does it feel good waking up to a solution the day after a night of troubleshooting.
Thank you Kaiochao, you've been a great asset to my project as of late. | |
That proc has proven to be extremely useful. It not only fixed my stackables issue but made a handful of other adjustments needed for converting my items to this database structure easier than they would have been otherwise(Looking for ammunition for example). Thanks again.
| |
Some more useful information that fits this snippet's theme is use of modified types. Take a look at the reference entry for newlist if you're not familiar with it.
I personally love it and feel more should be taking advantage of it. You are able to keep compile time minimal by doing so and keep your code pretty clean. | |
Modified types actually create an inline type definition, so it's identical to standard type definition at compile time.
| |
I'll admit I've never seen another platform where it was common in development to define a class specifically to create variations of the original class's variables, and I've only ever seen professionally developed games use external files that determine all values for these variations which are then loaded at runtime, I don't see much of a good reason for this type of databasing in BYOND.
If you don't intend to place things on the map, or use the map editor at all, or the map editor is not a crucial part of your game, then I'd say go for it. Otherwise, you're making a lot of extra work for yourself for little or no gain.
I didn't read any of the comments, btw. I'm ignorant.
PS: Amnesia and Penumbra are written in I think C# or Java (maybe C++???), and they used classes to create individual variations of the monster type. No text-file database or anything.