Rob's Notes (LIAV)

From EQUIS Lab Wiki

Contents 1 Immediate goals 2 News 3 Server Versus Client 3.1 Server 3.2 Client 4 Our Terminology / New Architecture 4.1 Architectural Changes (Data sending) 5 First Milestone To Do List 6 Sugar 6.1 Compiler Warnings 6.2 GUI 6.3 Fading

Immediate goals

• Look at AvatarData and VillagerData and make sure they meet the new requirements for making them stores
• Make sure Avatar gets along well with the new AvatarData

News

• The PLSM2 seems to have some kind of stable version for our latest version of Ogre. Since LIAV Land might get huge as it gets multiplayer, maybe we should integrate that again. Who knows what this will mean to physics.
  • Graham 13:11, 16 May 2006 (EDT) We've been down this road before. ;-) PLSM2 has always given us headaches in the past. It'd be nice if it's actually working this time around. But it would break a bunch of stuff. E.g., I seem to recall that pathfinding might break.

Server Versus Client

Server

• Pathfinding
• Physics
• Rule Application
• Resource Consumption
• Mob Movement
• Building Management
• Data of PC's possesions
• Positions of Buildings
• Agent Positions
• PC Positions

Client

• Physics
• Mob Prediction
• Housing Placement
• Environment
• 3D Rendering
• Input
• Sound

Our Terminology / New Architecture

• Entity (CAXWorldObject)
  • Mob - An entity which moves (CAXMob)
    • PC - Player Characters (CAXPlayer)
    • Agent - Computer controlled character (CAXAgent)
      • Villager - Special case (CAXVillager)
      • NPC - Merchants, things that talk (CAXNPC)
      • Beasts - Mounts, Critters (CAXBeast)
  • Immob (CAXImmob)
    • Building (CAXBuilding)
    • Resource Node (CAXResourceNode)
    • Resource (CAXResource)

We're not going to go crazy and try to implement all of these immediately. Creating a few months work will not get it done faster. All we need will be Mob, PC, Agent (which can be the villager for now), Immob, Building, and Resource. Most of these already exist, and just need to be bent into the new organization.

Maybe the Resource / Resource Node difference can be twisted into the same thing, a node being a special case of a resource. That might not be a good idea.

Architectural Changes (Data sending)

We've determined that our system of making this MMO worthy is to divide the data of the world objects into different sets. About two:

• Data that the client has to send up to the server
• Data that the client does not have to send up to the server

This has started to be implemented with stuff like CAXBuilding and CAXBuildingData for all of the classes which have derived from CAXWorldObject. We want to transmit the new positions and actions of the player, but not the frame of animation. We should lump this extra data into its own class. Does each object need it's own data class

For lack of a better title, we named it "Gameplay Critical" and "!Gameplay Critical". The non-gameplay critical elements can be taken care of locally.

First Milestone To Do List

The first step to get LIAV ready to be made multiplayer. This is a very generous list, and it's possible that certain items won't make it. It would be nice to have a solid foundation, which is what this first step is all about.

• Code
  • Pepper code with asserts to cut down on mystery crashes
    • There seems to be one in the pathfinding, or some other thread, that's a good place to start
  • Refactor certain classes (no need to have exampleframelistener and exampleapplication anymore, they can be merged)
  • Make sure doxygen comments are still being used
• Resources / Buildings / Immobs (restruction their definitions)
  • Create .immob definition files:
    • Immob definition contains a handful of states (identified by a strings)
      • Each state has a mesh & bounding box
      • Each state optional animation-state reference
  • Building definitions should now have:
    • A references to an immob for in game 'physical' representation
    • Building prerequisites (other buildings)
    • Building costs (tied into resource system)
    • Building attributes (gives new villager, makes people happy, produces chickens)
  • Resource Definitions
    • The resources file should contain information for each resource type
      • Is it a node/scatter resource, what are the models
      • Is it a straight-from-the-node resource collection (like a gold mine)
      • Immobs for resource nodes should optionally support 'tapped' and 'untapped' states

Sugar

Nice things I'd like to implement (depending on how trivial they are)

Compiler Warnings

There are some warnings dealing with sprintf and other things. Maybe we can fix that. fopen is throwing errors due to deprecation, we could be using fstream there.

GUI

This thing is going to need a GUI eventually. It might help with debugging (a console) in the meantime. Since I've refactored the core classes a little bit, I think it might be easier to drop in CEGUI. But there is work to do before getting around to this.

Fading

When things disappear, some fading affect would be nice. This one is at the very bottom of the barrel of things to do.