[CF-Devel] Future crossfire changes/projects
Mike Ponicki
sniper at citilink.com
Wed May 16 15:04:02 CDT 2001
just for some input:
wow! I really like this, and could see it fitting into crossfire
perfectly. not only is the quality good, but the art captures the
"fantasy" feeling perfect- they may not be 3d, but any RPG fan looking at
them would be like, "hmmm, nice graphics"
-Sniper
sniper at citilink.com
On Wed, 16 May 2001, Michael Toennies wrote:
>
You should know that there is one great chance for
>
changing to isometric gfx.
>
>
David Gervais, a prof. artist which has drawn for some full price games
>
and which has served CF in the last month with some tiles of his free
>
monsters/tiles
>
set, has started a true isometric tile set.
>
>
Look at this:
http://dgrealm.50megs.com/iso-samples.html
>
>
Well, if we can do it in this way, we can also talk about ONE skin design
>
for linux and/or windows client.
>
>
Of course, in style and tiles, there must be some small changes to fit it in
>
CF,
>
but the engine then should be useable for all newer items.
>
>
The problems is, that DG is at the moment focused at on tile.
>
>
Btw: for this style, monsters will look very VERY improved, when they can
>
turn in 8 directions.
>
This will give a great realistic look. Because only monsters must have this
>
directions (map
>
itself will not turn, forget the compass), it will be not so much work.
>
>
The great thing is, that there is a great chance to inlcude DG in Crossfire!
>
This thing is his baby, so i don't think he will skip the chance to include
>
this
>
gfx system in a great engine like CF.
>
>
I had think about this isometric changing in the past, so i can tell you
>
that is will be easy
>
to change client/server to this. 90% work are the gfx, the whole
>
gameplay/server will be the same.
>
>
>
> Now that 1.0 is out, I'd like to get a little discussion/input on future
>
> changes for crossfire (say 2.0). I'm trying to keep these a bit
>
> more general in
>
> nature and not go into details of exactly how feasible different
>
> options are (as
>
> other changes may make some things easier or harder to do). This
>
> is also to
>
> make it aware to others possible projects they may want to take
>
> on. I'm also
>
> trying to limit to big and/or controversial projects. Doing
>
> something like
>
> adding a new spell isn't going to make this list.
>
>
>
> If you followup, it is probably worth while to start a thread
>
> for each of the
>
> proposed changes, so that conversation on each one is easier.
>
> Using the brief
>
> description in the Change line for subject is probably a good idea.
>
>
>
> General template I'm using:
>
> Proposed Change: Brief description of change
>
> Details: More detail on the change and other notes
>
> Pros & Cons: possible benefits
>
>
>
> So on to my list:
>
>
>
> Change: Increase viewable area of map
>
> Details: Currently, the viewable area of the map window is 11x11.
>
> this change
>
> suggests making this area 17x17 or some other number (best
>
> solution would be to
>
> have this a config option).
>
> Pros: Larger viewable area gives more glitz to the client. Most
>
> games have a
>
> much larger viewable area. Beyond the glitz factor, I think this
>
> may improve
>
> play/strategy. On a 11x11 map, the farthest a monster can be and
>
> still in site
>
> is basically 4 spaces (monster being on the 5th). If the size is
>
> 17x17, this
>
> now increases to 7 spaces, giving more oppurtunity to notice
>
> spells and other
>
> effects.
>
> Cons: Larger maps means more bandwidth to get updates. This may
>
> break/weaken
>
> some maps (ie, a map where you pull a lever and cannot currently see the
>
> result. OTOH, if youu have 2 players cooperating, they see that
>
> anyways).
>
> Things like the world maps wouldn't have enough padding spaces beyond the
>
> exits. Some maps may hide big treasures/monsters currently out
>
> of sight, but
>
> I'm not really sure the problem if that becomes visible. This
>
> change would
>
> require clients to get updated.
>
>
>
>
>
> Change: Improved client/server communication
>
> Details: This is intentionally broad - looking for input for
>
> things that should
>
> get improved. One thing that definately should get changed is
>
> text messages
>
> should have a content type instead of sending color type - this
>
> change would let
>
> the client choose the color and potentially other informatiion (font, what
>
> window to draw it to, etc.)
>
> Another case would be to improve ground object handling (for
>
> example, if on a
>
> very large pile, sending more objects each tick, so if you stand
>
> there, the
>
> entire stack might get sent).
>
> Pros: Should make the game more playable
>
> Cons: obsoletes old clients, don't want to do features that are a
>
> lot of work to
>
> do but give little gain.
>
>
>
> Change: Performance improvements
>
> Details: Currently, crossfire has some pretty severe performance
>
> issues when
>
> dealing with lots of spell objects. Very large maps can 'freeze'
>
> the server
>
> while loading. Likely to be other areas where performance is not
>
> very good.
>
> These should get fixed up.
>
> Pros: Improved performance is always a good thing.
>
> Cons: Some changes may be difficult to make or involve lots of
>
> code changes (and
>
> hence lots of potential bugs). Areas of improvement should really get
>
> identified so areas that don't have any real problem don't get worked on.
>
>
>
> Change: Improve NPC communication/scripting
>
> Details: Currently, it can be very difficult to hold a
>
> conversation with an npc
>
> because the communication is stateless and it isn't always to
>
> figure out the
>
> keywords. More advanced scripting would also allow for more
>
> complicated npc's
>
> (or remove the need of linking a bunch of objects to mimic some
>
> communication)
>
> Pros: improved communication is desirable
>
> Cons: May requiring redoing a lot of npcs. If an external
>
> scripting language is
>
> used, has the potential problem of reliability issues (external
>
> script could
>
> hang server by never returning)
>
>
>
> Change: New map editor
>
> Details: Currently, crossedit is basically unmaintained, and
>
> buggy. Ideally a
>
> replacement would be less buggy and more maintainable (if it was
>
> written in GTK,
>
> for example, at least its using the same toolkit as the client). However,
>
> something more portable so that windows and mac could use it
>
> would allow more
>
> people to design maps.
>
> Pros: More reliable editor
>
> Cons: May be a lot of work for not a great leap in reliability.
>
> If written in
>
> GTK, may lack portability to windows/mac (dunno if there is gtk
>
> port to those
>
> systems). If not written in gtk, it then lacks commonality with
>
> client, so its
>
> yet another toolkit that people need to learn (IMO, on reason
>
> currently client
>
> is largely unmaintained is no one really wants to learn Xt at
>
> this point in
>
> time)
>
>
>
> Change: Clean up object structure
>
> Details: Currently, values in the object structure has different meanings
>
> depending on the type of object - for example, sp has nothing to do with
>
> spellpoints when used with exits. This inconsistent use leads to
>
> problems (ie,
>
> sp regen speed bug when using permanent experience). Idea could
>
> be taken to
>
> several different levels:
>
> 1) Basic - just add enough unique elements to object struct so
>
> nothing gets
>
> re-used with these conflicting values. Str always means
>
> strength. This would
>
> result in higher memory usage
>
> 2) Go to object type/subtype setup. So equipment would be a
>
> major type, with
>
> its own substructure type, creatues another major type, exits/transporters
>
> another, etc - roughly a dozen major object types with subtypes.
>
> Within each
>
> major type, all the values mean the same thing. This is a lot of
>
> work, and I'm
>
> not sure the work is worth the gain.
>
> Related: Remove integer values from archetypes/maps and use string names.
>
> Instead of attacktype 5, it would be attacktype
>
> physical|electricity. This
>
> would likely reduce bugs in archetypes, and make them much easier
>
> to read.
>
> downside of this is a bit worse performance loading these things up.
>
> Pros: In the long run, may make things more stable as values
>
> don't get tromped
>
> over for other uses. If option #2 is taken, may make things more
>
> modular, and
>
> more extensible (adding a new equipment subtype easier - since
>
> most functions
>
> would deal with the main equipment type in the same fashion,
>
> supporting a new
>
> subtype may not require any more changes than just for the equip logic)
>
> Cons: Likely to introduce new bugs. Potential for more memory
>
> consumption & a
>
> lot of work (depending on which of these options is taken)
>
>
>
> Change: Have tiling of maps done automatically by server
>
> Details: Currently, tiling (ie, the world maps) is done by
>
> duplicating spaces
>
> from neighboring map and lining the map with invisible exits.
>
> This more or less
>
> works, but has some problems (things don't always line up quite
>
> right). One
>
> example I can think of is the wyvern question - if you come into
>
> that square
>
> from the south, your are on a different map and don't hit it.
>
> The idea here
>
> would be that there would be logic that says 'use map xyz for
>
> east, abc for
>
> north, and qwe for south'. As the player approaches the east
>
> edge of a map, the
>
> server would see that xyz is to the east, load it up, and display
>
> the spaces on
>
> that map as the player gets closer to the edge, and automatically
>
> handle when
>
> the player moves over.
>
> This also has an advantage in that you can synthesize layers.
>
> Imagine for
>
> example a tower with the balcony on the south side on say floors
>
> 2 and 3. With
>
> tiling, for levels 2 and 3, you could specify that south map is
>
> 'towerentry'.
>
> So as you stand on the balcony of either level 2 and 3, you would
>
> see this map.
>
> If someone walked up to the tower, both players on level 2 and 3
>
> would see this
>
> player. but towerentry itself would say map north is tower1, so
>
> they would
>
> disappear into the first floor. If one of the players jumped off
>
> the balcony,
>
> they would once again be on this entry map, and as they went
>
> north, be on the
>
> first level again.
>
> Pros: Would make map designing of large maps easier. Could have some cool
>
> advantages
>
> Cons: Could be a bit of work for the benefits gained.
>
>
>
> Change: Increase outdoor map scale
>
> Details:
>
> Main issue is that the continent itself is quite small relative
>
> to other maps -
>
> in apparant scale, the continent is only 2-3 times larger than the city.
>
> There are 3 main points on how to do this (I'm going to include
>
> pros/cons with
>
> each one)
>
> 1) just take the world maps, and blow them up by 2,3,4 (or more)
>
> times. Do some
>
> cleanup so they aren't
>
> so blocky (as well as exits). Pro: Easy to do. Con: there is
>
> still a disparate
>
> scale
>
> 2) unified outdoor scale. In this mode, things like the city
>
> would actually be
>
> on the world maps (so you have the same scale inside and outside the city
>
> gates). Pros: Unifies 'outdoor' scale. Puts cities actually in
>
> the world map,
>
> so various spells or other abilities could let you bypass gates
>
> and so forth,
>
> giving the game more potential character. Cons: A bit more
>
> effort to do. May
>
> open things up to abuses.
>
> 3) Totally unified scale. This basically takes #2 above and extends it to
>
> everything. So shops are just 20x20 blocks actually located
>
> within the city,
>
> which is located with the world as a large. This would make
>
> everything much
>
> bigger (cities would have to be several hundred spaces across
>
> just to hold all
>
> the dungeons, shops, etc). Going accross country really would be a major
>
> journey. Pros: Basically takes what maps we have now and creates
>
> an apparantly
>
> huge world. May let players find maps they otherwise wouldn't (I
>
> know for a
>
> fact I don't try every house in the city, since 90% are closed,
>
> but if your
>
> taking a shortcut accross some area, you may notice some monsters in some
>
> house). Cons: A lot more work - this could probably be done
>
> more piecemeal.
>
> May make the scale too big (very hard to find some dungeons for example).
>
> Definately would want automatic tiling if this is done.
>
>
>
> Change: Allow transportation objects
>
> Details: Basically allow things like horses, dragons, boats, etc
>
> which speed up
>
> travel time or let you travel over types of terrain you normally
>
> could not go
>
> over.
>
> Pros: Adds some neat abilities
>
> Cons: Ability to travel over some types of spaces may open up
>
> abuses (ie, easy
>
> to get some quests, etc). Demand for this may not be really high?
>
>
>
> Change: Spell objects
>
> Details: remove spellist.h and spells.h file - instead have all
>
> that information
>
> contained in archetypes. Rely on archetype data for more
>
> information for spells
>
> (ie, size of explosion for the variosu fireballs would be by
>
> value in arch). A
>
> players known spells would be these spell archetypes in the
>
> players inventory.
>
> These archetypes would also be mutable, so someone could easily
>
> make a 'mega
>
> fireball' by taking a large fireball spell object, increase sp
>
> and size, and
>
> putting it in a spellbooks (spellbooks would basically be a book
>
> with a spell
>
> object within it - if player successfully learns it, this object
>
> goes from book
>
> to player object)
>
> Pros: Make spells much more extensible, and may actually reduce
>
> amount of code
>
> (as more data would come from archetypes and not values in the
>
> code itself)
>
> Cons: Likely to be some performance hit. Mapmakers could put out
>
> abusive spells
>
> (but no worse than right now with abusive objects I would guess)
>
>
>
> Phew. Longer than I thought it would be.
>
> _______________________________________________
>
> crossfire-devel mailing list
>
>
crossfire-devel at lists.real-time.com
>
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
>
>
>
_______________________________________________
>
crossfire-devel mailing list
>
crossfire-devel at lists.real-time.com
>
https://mailman.real-time.com/mailman/listinfo/crossfire-devel
>
More information about the crossfire
mailing list