having read the source quite much, I believe that many elements of the game could be stored in easily modifiable XML-files (eXtra Modding Liberty), ultimately making the game much more flexible both for modders and core developers. XML-ifying would make it easy to add new sites, character types, weapons... well, new anything, as well as making it easier to modify the existing ones.
Remember, creature types are not fully described by their entries in creature/creaturetypes.cpp. For instance, special attacks are handled in combat/fight.cpp, sleeper liberal activism is handled in a different place, aging effects in daily/daily.cpp can even change a creature type. Do a grep for CREATURE_ if you're interested in finding (hopefully) every instance of this. The same sort of thing applies to sites (special handling in all sorts of places), vehicles, etc..
If you tried to put creature definitions into data files while keeping all this "switch polymorphic" code in place you'd end up either with a very poor extension facility (since you wouldn't be able to add special attacks and such things) or hugely complicated code (since you'd have to carry information about the creature types to everywhere they're used). The solution? Define an interface for creatures that allows client code to not mention specific creature types. Since this is C++ you might as well even go all object-oriented with it and go with a Creature class that encapsulates all features you might want to customise per creature type - and when you can define all the features of a creature in one place it should be easier to figure out what should go into the data file, too.
For instance, things like special attacks could be handled by giving the Creature class an attack() method that takes another Creature as an argument and where the attacker object decides precisely what kind of attack to make. Alternatively, less pure-OO-ly, it could have a public attribute describing what kind of special attack it uses. Optimally every mention of specific creature types outside the Creature class definition should be removable, but do note that this means the interface will have all sorts of niggly little facets in it, for instance it will have to have some way to determine if the creature should age, and if it should perhaps age into a different creature type. For what it's worth there already is a Creature class but the only things it hides behind an interface are the attributes and skills.
Creatures are used absolutely everywhere so if you're actually interested in the task of reducing coupling in the code you should probably start with something less complicated... let's say cars for instance. I grepped the code for VEHICLE_ to see what I'm dealing with, and... if I were implementing this change, keeping in mind the intent to eventually start moving data off into data file, I'd probably make a CarType and Car class: CarTypes have a name, a price, a bool determining whether they can be for sale at the used car store, a security difficulty for approaching and touching, a heat and juice modifier for stealing, a difficulty for finding them off the street, a driveskill bonus, a set of appropriate colours, and a range of models (construction years) for old and new vehicles. Cars have a... actually, I think they only have a reference to a CarType for now - I was thinking of the plan to have per-car heat here, though. Check if there already is something like a Vehicle type or such and what it contains already. Once you've pulled together everything you need to describe a CarType and a Car, defined an interface for it, and written the code to slurp a definition file containing CarTypes into the game state, just change combat/chase.cpp, common/getnames.cpp, daily/activities.cpp, daily/shopnstuff.cpp and game.cpp accordingly.
See what I'm going for here? I'm far from an object purist who'll insist you do everything by message dispatch and never make any decisions based on any object that isn't *this (in fact if I'm a purist of anything it would be of functional languages), I'm just pointing out that before you can describe something in a data file you had better pull together all the code depending on that description.
(if I'm talking out of my ass, I'd appreciate it if Carlos Gustavos called me out: How are you going to go about from having parsed the data describing a car type to having the shop know its price, for instance?)
If all you want to do is modify numbers, yes. If you want to actually have different effects for items and the ability for modders to do something without modifying the core binary, then XML is woefully under-featured. Seems like it'd be smarter to work at hooking in Lua or Boost::Python into LCS and converting as much non-core game logic to something that's actually meant to be modified.
Ehh, LCS doesn't have a lot of core game logic that you wouldn't likely be interested in modifying, and it also doesn't have an engine with strict performance requirements. It would be difficult to come up with a place to start hooking Python or Lua into. I'd say keep the whole thing C++, and if someone wants to develop LCS in Python, they can reimplement their own from scratch.
More generally, I think the one thing I would work on if I were intent on committing acts of software engineering on LCS would be hooking in a good widget library (hopefully without having to write one first) and converting as much code as I can to use it. I'm very much not a fan of reimplementing things like menus and paged lists every time there's need for one, as it causes complexity and LOC blowups, and most of all discourages someone like me who doesn't just know offhand what code to copypaste in from doing things like tossing up a list because it's unnecessarily much effort to get it right - thus making modding (of the actually interesting, adding-new-features kind) more difficult. Might as well do things like add a message buffer and see about making the interface scalable to different terminal sizes while one was at it.
I'm not going to do it since I'm lazy. But I'm putting the idea out there because in my opinion the lack of a UI library is the worst problem holding back interesting development on LCS, and the one part of it that could be improved with very little risk of getting it wrong and making the game more difficult to mod rather than less difficult.
Author
Topic: LCS and XML (Read 5786 times)