Learn C++ is one of the more basic answers that really doesn't explain to anyone how to make a custom system within flyff but, yeah, you should learn it.
it really depends on the system you want to make. A better thing to learn is the design pattern of the game and how to integrate features.
Network:
DP____ files are server/client packet handles.
DB____ files are files that access the DB using the CQuery object, which generally handled in a winthread.
Object:
Mover___ files are related to player and monster objects.
Cctrl = control objects (dynamic objects)
CommonCtrl = dynamic control objects that require more information. (you can do a lot here)
CObj = base object.
model:
Cobject3d = actual 3d model info with the other struct in it.
ModelElem = the model information and model elements (for players they render gear pieces etc)
User in worldserver = worldserver specific user information and an extention of cmover.
Material = Object matieral stuff.
CMotion = Motion data / animation data
CBones = Bone data.
Windows:
Wndbase = base window layer
CWndNeuz = more so the base window layer if you look in the source that you'll mainly use for applets.
File Info:
CProject = contains most data formats and reading the resource files that is global and isnt stored via singleton like CUltimateWeapon.
CScanner/CScript = text file parsing
CFileIO / Cresfile = file loading
CItemBase/CItemElem = item data.
CItem = item objects
Map Info:
LinkMap = map separation based on grid zones to separate objects from zones (its why you cant see monsters passed a certain distance) and also separates objects by type like dynamic and static.
LayeredLinkMap = Layer information and above. E.g: Azria has channels, and dungeons.
Landscape.lnd section of map. the size of it being a MAP_SIZE + 1 x MAP_SIZE + 1 grid ( 16641).
Water and the Height Attributes are bound to a different grid within that grid of 16x16. (256)
These 16x16 grids are landscape Patches.
LandLayer contains a texture, lightmap, for the entire map_size and a boolean per 16x16 to enable the texture in the patch.
CPatch = since the size of an LND is 128 and if there is 16x16 patches per landscape, that means a Patch Size would be 8. (128/16).
This makes a patch an 8x8 grid of quads which contains 9x9 vertices indexed. (rendering changes a bit based on lod)
(textures can be applied to individual vertexes because of the lightmap being the same size as the mapsize and the lightmap is modulate2x'd with the textures. My assumption is that the game handles the transparency with the lightmap and the editor handles that logic to set it. And then color setting is its own landlayer or color is also updated within each texture set (should probably be a once per last thing though for better blending). Within atools if you set none to texture it will remove the entire patch.)
mpu = map per unit or something. its used to make the map vertexes more distant in space with the games internal positioning.
Region = map region data (zone names, is zone pk / town, is it a teleport zone)
Respawn = games respawn handlers reading data from region if i remember correctly. Spawns items on the map or monsters over time.
World = handles the world data (a few landscapes or the entire world on server)
dyo = npc spawns
other:
AttackArbiter = damage calculations
Music = music implementation... with miles or old fmod.
2dRender = handles the games 2d rendering (like rendering lines and textures / textures in a square.
d3dapp = games directx window handling
Neuzmsgproc = Entry point for the game
Neuz = Extension of the d3dapp containing data related to the game rather than the directx renderer backend.
DSUtil = DirectSound implementation
AI__ files are related to monster AI and is a mixture of FSM (finite state machine) and a Behavior Tree.
The game goes through a state / process / action.... type ... message system for objects and processing movement and actions. This is another Finite State Machine. E.g: press jump key -> is allowed state -> jump 1 (inital jump start) -> jump 2 (going up) -> jump 3 (falling down) -> jump4 (landed). Anyway this is related to Movermsg and ActionMover.
buff = buffs / debuffs on an object. some things like stun etc is handled via object states and a mover variable. This is also the case for poison and bleeding even though you can apply a debuff the damage and "effect' is handled in the mover class. It is possible to swap it in to buffs.
When you start breaking the game down in actual components, it becomes easier to read, understand, implement and create. An example is making professions: Project to read the file and store info. Mover to store level and profession xp, dp for network transfer, db files to store / read from db. UI extends CWndNeuz. can create a custom state like 'harvest' or 'mining' to handle the object state and then setting the Motion. Can add a server time check to see if they complete it just like collecting. Can create a custom object either through ccommonctrl or ctrl or even a sfx (but sfx is client only), can spawn them in through the rgn file / region file in the world or load in a separate file. Crafting an item would send a packet from the client to the server, check your requirements to complete that, and then update the client.
Need any more information on files?
