On 3/18/09, Per Inge Mathisen <[email protected]> wrote:
> First, the great majority of volunteer contributions to games happen
> to be maps. Plain maps with standard rules. This is also the most
> popular non-core contribution in almost any game that have them. Just
> more of the same. People apparently like variety over a common theme,
> while learning arbitrary new rules just to play can be a bother.
While true, the main reason for this is that 'mods' are much more
difficult to make, since you can't really 'paint' a mod, like you
basically do with a map.
> Second, the canonical examples of great mods are not really mods at
> all - they are total conversions. They strip the existing game down to
> its bare bone engine and build it up again with new stuff. The first
> Counterstrike is a great example of this. Some of the more popular
> Starcraft "mods" are maps that are scripted to work by totally
> different rules altogether, they do not seem like playing regular
> Starcraft at all, and work more like miniature total conversions than
> small modifications ("mods").
While this would be most welcomed, it is also the most difficult to do.
Warzone isn't really mod friendly at all, and one small mistake and
the game crashes, and the odds of finding out what caused it can be
pretty long sometimes.
> Third, maintaining small modifications (mods) to a large core of
> rapidly moving game code is a nightmare. Open source developers do not
> like stable interfaces, and even when they claim to and the interface
> is purported to be stable, then it just so happens that if they are
> not continually tested as part of the core game rules (or by unit
> tests - which also happen not to be popular), they fall prey to rapid
> bit rot and become broken. Popular suggested or created modifications
> to the game rules quickly become integrated into the core rules,
> draining the pool of mods available for players.
True again, which is why the mods that are floating around now (and
some are supposed to be quite good) may not work in the future, and
without active development & testing all the time, as the source code
changes, it makes it a very difficult problem to handle.
> As for Warzone, we are facing the same issues, just that we are now
> where Freeciv was ten years ago. Our mean number of working, complete
> mods is zero. That is, if we do not count Rebalance, which is an
> exception that pretty much proves my point, since not only was the mod
> absorbed into our core, we even assimilated its developer... ;-) So
> let's not make the same mistakes that Freeciv did. Users in general
> are not going to learn the arcane switches and incantations necessary
> for making mods work (--mod_mp?), and as long as we refuse to greatly
> simplify the way mods are treated, we will not be able to offer an
> appealing user interface for users to access them.
The mistakes we made:
A) it is *too easy* to add mods, (stick them in the auto-load
directory and that is it). (By that, I mean it is too easy for new
people to throw everything they download into that auto-load folder.
If they crash, and do bug reports, we have no clue what is going on,
or how they got to this point.)
B) it is *not possible* to track which mod people are using.
(would need something like the addon.lev files for mods, so we could
track these things)
C) it is *not possible* to turn mods on/off. (I mean for users to do
this. I know we could reset physFS's search path to be 'virgin', and
ignore everything.)
D) it is *not possible* to easily know which mod conflicts with each other.
Roman & gang solved some of this in the past with warzone starter.
(http://docs.wz2100.net/wzstarterguide/WZSuserguide%5B1%5D.html)
This allowed players to pick AIs, and which mods /maps to use.
They more or less did this by copying stuff to the correct location,
which is how all warzone 'mods' work, via the override system.
I am unaware what went on in MP games though, since I know there is no
code in the codebase to transfer mods, and only transfer maps, but
perhaps gamespy had additional stuff going on behind the scenes?
> What we need first and foremost is an easier way for users to create,
> distribute and download maps.
went into this last time.
> After that we need a better way to offer users a way to install and
> play total modifications. Those are either new campaigns, or totally
> different and network incompatible multiplayer/skirmish games using
> their own AIs and own game data. Overriding base game data is a risky
> way to create them, since even small changes to non-overridden base
> data could break it. So the best way to create them is to replace
> everything. Then we can offer a menu where such conversions can be
> chosen.
What we need is a QT4 version of warzone starter for starters, and we
also have to have a way to identify what the mod does, and what it
changes.
It really isn't needed to pack everything into the mod, once we know
what it touches.
> As for the small mods that just change one or two things, like
> increasing mg firepower or adding flying trucks... I dare say they are
> by and large not needed, and won't be used, except as a proof of
> concept. For that you can use ordinary patches to the core game data,
> and deal with them like we deal with code patches. In the long run,
> supporting them is probably harmful.
I dunno if they are not needed, since I feel if they want to do that,
then they can, but they should do it correctly.
> So in order to get good support for user modifications, we should
> remove support for mods.
Not sure 'remove' is the correct word, I tend to think we should make
it so future mods follow the rules, and hopefully good things can come
out of this, but I do think that we should get rid of the auto-load
directory ASAP, and have people use the command line, for now, to add
mods. At least then, when it crashes, we can tell what they were
running via the crash dump, and the command line it dumps out in the
dump file.
Of course, with a new GUI, a warzone starter type application won't
really be needed...
Lots of other problems can be solved with a new GUI as well.
Too bad we lack resources to finish everything we want quickly.
_______________________________________________
Warzone-dev mailing list
[email protected]
https://mail.gna.org/listinfo/warzone-dev
