Were there any plans to change the way information about items and creatures is being stored?
It seems like all of that information is hard-coded right into the various initXXX methods (e.g. initRings, initWildLife) at the moment.
Wouldn't it be easier to add and update all of that content if it was stored externally in, for example, formatted text files of some kind?
If it sounds like something that might be worth pursuing I wouldn't mind discussing it in more detail and/or working to implement it -- I've done some similar things in the past.
Anyway, just an idea.
Tyrant is great fun -- keep up the good work! :)
It's actually not at all hard to maintain data within the code - you only have to write a few lines of property setters so it isn't much of a burden. e.g.
Java costs you a few extra characters, but lets you have much more flexibility when you want to do something interesting like calculate a property value based on some other properties.
Ideally, it would be nice to separate out the object database into separate files, but it would be really hard to do because you'd have to write pretty much a complete scripting language parser to cover Scripts, Modifiers and suchlike. Even worse are the objects that are generated by code (e.g. the potions, scrolls etc.).
e.g. within a loop:
t.set("Name","potion of "+effectName);
For all these reasons, I think that separating the Tyrant library generation code into separate data files is an interesting project, but will ultimately boil down to implementing a full parser/interpreter (and maybe even a compiler?). Not an easy project, so I'm not sure it's worth the effort.
No argument about the actual complexity of maintaining the data in place in the code, but it does require that Tyrant be recompiled every time you make a change, which was more of the kind of hassle I was thinking of.
I agree that to replace all of the capabilities of generating the objects in the code with an outside set of files is a substantial undertaking, but a middle ground might exist too where simple objects can be moved out of code for "ease of tweaking" and more complex sets of objects still generated directly.
Creating some alternative for building objects might open up some different possibilities for adding new content in the long run, too. Though that may be a bit of a tangent to the original spirit of Tyrant.
Anyway, just a thought.
Certainly a possibility - and in fact rather similar to what we can do now with the map editor.
Not sure it should be a priority though. Adding Java code and recompiling is just as easy as adding to a text file when you have your development environment set up properly. The text friles would still have to be in CVS and included in the build after all.....
When I first saw that all the world's items were generated in the code, I almost fell out of my chair. However... after reading mikera's post and thinking about it, I admit it works pretty well...
That being said, I've worked on a simple xml parser derived from the (apparently) now-defunct TinyXML. With the "Thing" structure Tyrant uses, it seems like it would be pretty simple to do t.set(elementName, value)
Scripts could be looked up by name.... But that seems troublesome...
Having this data stored in plain text files would make it much easier for people not skilled in java to contibute to the project. For someone without basic java skills, it's likely they would run afoul of classpath or ant problems before creating a single object.
XML files could be edited by hand or by a simple editor, either stand-alone or attached to Tyrant, like the map editor.
It would also be great to have the save games in something a bit more stable than serialized files, but that's an even larger task :P.
Just a thought
I'm working on a re-architecture of BaseObject (and thus, all Things and Items) and Lib to replace all String properties with actual getters/setters. All sub-types are actual subclasses, so for example Armour extends Item and implements IWieldable.
I've modified the serialization system to only save data that is different from the parent Template object, and as long as any new properties have defaults that make sense for a pre-existing item, serialization/deserialization should be backwards compatable.
I have it working for basic properties, and am going to attack Scripts next. The new architecture uses Introspection, so my initial attempt will be to use actual bean properties for scripting.
Once I get that working, I'm going to do XML serialization/deserialization. This will allow for replacing the entire library with completely different items. For example, you could create a Sci-Fi game with the Tyrant engine by simply loading a different XML library.
Of course, this is pretty slow going, and I have no idea how long this will take, as my "real job" is starting to get pretty hectic right now.
This is the "classic" OO approach and it was the design that Tyrant used originally, but it turned out to be very painful to implement.
I spent a lot of time refactoring to the prototype based model that Tyrant currently uses, and rather like the way that it currently works.
What problem are you actually trying to solve? The current model is after all about as flexible as you can get.
My main issue is that the save files get over half a meg, and take for ever to load at higher levels. I've seen other posts from people with slower computers say it already takes them over a minute to load a savegame. I can log into Worlds of Warcraft faster than that.
I believe this is because everything is saved as string properties, as well as there being too much stuff in the savegame data. It looks like the entire Library of Things is serialized, but that should be the same for every game. Unfortunately, it cannot currently, because things like "IsIdentified" is stored directly in the lib, as well as things that change, like recipes and potion, wand, book and scroll names. I'm going to try to store those mappings externally.
I feel that the game is currently very tiny, and as the development progresses, it could become easily four times as large, once quests and new dungeons are added. If this happens, the save files will be over 2MB, and take 15 seconds to load on my 2-CPU 3.0GHz P4. There is no reason such a simple game as this should have a noticeable load time.
Yes, the current system is VERY flexible, and I think that is great! I hope to come up with a design that keeps as much of that flexibility and simplicity as possible. So far, I've been able to keep all the complex stuff in the base class, so anyone extending that doesn't have to worry about it.
While I WILL donate my code when I'm done, or maybe even earlier, similar to the other re-architecting project, I am NOT working on this with any expectation that you will adopt it (if any of these crazy ideas even work out), and I will NOT fork a competing project. I'm doing this because, as my wife puts it, I have "a very strange definition of "fun"."
Not to mention that your belief that OO made your program inflexible raised my programmer hackles... "Thems' fightn' wurds!" :-)
(Sorry about that last bit. You can get a Montanan out of Montana...)
XML serialisation would be nice, though the Script objects bugger this up slightly. You basically need serialisation IDs to make sure that the right Script instance gets generated
Ideally I'd like to replace all the scripts with a mini-scripting langauage but that's rather a big project to take on - it would have to be a proper turing-complete language with a lot of Tyrant-specific customisation.
this was a goal in Tyrant II, my version of Tyrant when mikera went missing. It is quite a bit of work, and that work could be used for the addition of some other features/balancing ;D
Finally, somebody came up with the idea of using a scripting language!
May I point you all to http://www.beanshell.org/ ?
Believe me or not, it's a full-blown Java interpreter. It's small and elegant. And it's as easy to embed as it gets.
as a counter argument, I would much prefer JudoScript, it has everything BeanShell has and then some more. Mostly enhanced datastructures and domain specific stuff.
PS : http://www.judoscript.com
And we must not forget the even better choice of Groovy.
>And we must not forget the even better choice of
Man, you better be kidding. Groovy is a pile.
The only place here this would be a real help is to make a header file for the graphics. You know silvery crown is such and such in a file or the green effect would be gas.annimation is xxx.in a file..
That would be the "ImageSource" and "Image" properties for every object.
It would be a simple five-liner to run through the entire library and print them all to System.println().........
Log in to post a comment.