[crossfire] Crossfire release?

[Mark Wedel]

On 11/22/10 10:19 AM, Nicolas Weeger wrote:
>>    Client too old may be reasonable - at some point, the older clients
>> really will not work.
>>
>>    It isn't feasible of course to test every client with every version of
>> the server, and vice versa.  The problem of enforcing versions gets tricky
>> - one does not want to force version 1.60 client with 1.60 release, as
>> everyone with older clients now have to update right then to play.  But I
>> will verify that 1.50 client works properly, and if you are playing older
>> than that, probably time to update.
>
> Seems fine to me.
>
> Note there was a character creation bug that prevented creating new characters
> with some versions...

  I thought I had checked that, but apparently I missed it.


>>    Is that suggesting that maybe the java client should be the official
>> windows client.
>
> Is that a question? :)
>
> No, I'm not suggesting anything.
> But I admit to not having much interest in trying to build the GTK client
> under Windows.

  My take is that not many of the crossfire devs are particularly active 
developers on windows, which is why the glade/gtk issue persist.

  Java (in theory) is very cross platform, so can make for easy client for 
windows, mac osx, or anything else that can run java.

  A java client release (meaning posted to the sourceforge crossfire site) 
should probably be done to make it more known.


>>    Discussion of that probably gets beyond this message - but some of that
>> also goes into gameplay and other aspects - I certainly think it would be
>> good to have the recipe chains for alchemy be such that one could, through
>> alchemy, reasonably get high experience (this would involve making the
>> basic recipes much more easy to find or perhaps common knowledge (eg, each
>> time you gain a level in alchemy, you learn a recipe for that level).
>>
>>    The hard part IMO for quest chains/skill leveling is ideally, you want
>> the process of completely the quest to use the skill in question - having
>> an alchemy type quest which is to get the liver of the boss monster at a
>> bottom of a dungeon is fine, but one really isn't using alchemy (most
>> likely) to solve that quest.  A few of those may be reasonable, but I just
>> get the feeling that if too many are about, it might start to feel
>> somewhat artificial.
>
> Or have a quest in which you need to create via alchemy some specific item,
> requiring you to have a minimum alchemy level. Item that can't be traded, or
> just don't care if a player gets it from someone else.

  Or even quests/maps in which various materials are available (in chests, 
monster drops, etc) which allows one to use alchemy to make potions, bombs, etc 
to defeat some monsters - at least in that case, alchemy can be used to complete 
the quest.  A character could use other skills (and not use alchemy at all), but 
at least alchemy could be used heavily, so it makes more sense to get alchemy 
experience.

  It would perhaps also be interesting that if one makes a device through 
alchemy (dust as an example) and uses that dust to kill creatures, may some 
portion of that experience should go to alchemy.  Not sure how to do it all, and 
it probably has to be limited to the character that created the dust also using 
it.  But in a sense, you are putting your skill to the ultimate test there.

>
>
>>    Yes, but I'd almost be tempted that if redoing/adding a lot of graphics
>> get looked at, having an larger image set (64x64 base lets say) would be
>> nice, but that probably gets into the dreamworld below.
>
> I'd suggest either some vector-based solution, or why not 3D models - at 64x64
> for base tiles, I hope you can start to do nice things :)

  From having done this a few times (bitmap to xpm conversion, 24x24 to 32x32 
conversion), being able to populate the entire new image set is a big plus - in 
this case, that would mean having all images available as 64x64 images, even 
though they are just scaled up 32x32 images.

  Now at that point, how to clean those up is another question - for some number 
of images, probably just doing manual cleanup is fine.

  For some, it may be making a 3d model or other basis, and then doing 
manipulations on that and saving in 64x64 image may be best.  For something like 
some characters and monsters, making the 3d model which you can then rotate for 
the 8 different directions as well as do basic animation (moving arms/legs) may 
be a lot easier than actually drawing all those images by hand (but not having 
done much with 3d models, can't really say myself)

  For others, doing vector graphics and saving/converting those to 64x64 png 
images may make sense (for non animated objects that also wouldn't have any 
rotation, this may make sense - things like floors, walls, even fair number of 
items).

  Now at some point, things may be such that there are 100 3d models in the arch 
tree, and it then makes a lot more sense to send those models and have the 
client deal with them vs sending the 32 variations of each model.  Same 
potentially for vector graphics.

  But if there is only 3 3d models, at that point, it probably does not make 
sense to put that support in the client - there needs to be some critical mass.

  Note that a 64x64 image size was a somewhat arbitrary size - by it being an 
doubling of existing size, it means there shouldn't be as many/any artifacts 
from resizing are easier to deal with.  64x64 is also big enough that for the 
major of systems, that map window would fill the entire screen (64*25 is 1600 
for those not wanting to do the math) - yes, there are high resolutions than 
that, but in that case, the extra space would presumably be used for things like 
inventory or messages or whatnot.  But that doubling is size (really 4 times 
number of pixels) really should allow a lot more detail to be added.

  In short summary, if this was done (in dreamworld, but this is perhaps one of 
the easier pieces)
1) Make a big set of images by converting all existing images.
2) As cleanup of images move along, potentially use other formats as the 
'source' image to make things easier/better.
3) If enough of these source images are made, then look at adding support to 
send this to the client and let client do rendering/scaling.