This log is from 28. April 2002 - 2. Mostly Omnivore explaining some basics of gaming engines and objects and things, but IMO still has relevance and bits pertaining to this game.
It has been edited slightly, removing addresses and complely unrelated things. Note that my editing may not be perfect, and that some unrelated or partly unrelated things might be left. I have tried my best to not cut out too much, and thereby might have left in more than necessary. :P
This is as seen from EdorFaus' viewpoint, with his local times of the day. Raw log file(ASCII)


[12:29] <EdorFaus> ah there. mmosg log page created, automated, extended, twiddled with, and checked for HTML 
  4.01 Transitional compliance(index page was approved, too! :) and the others almost so :) )
[12:29] <EdorFaus> just too bad Kaelic isn't around :P
[12:37] * Omnivore still thinks you guys should make the basic server engine open source under the LGPL liscence 
  - does recommend keeping the core server side game code semi-private though
[12:38] <EdorFaus> that's sortof the plan, as far as I gathered... semi-open source, as in only show it to 
  trusted ppl :P
[12:38] <Omnivore> well the basic server engine should imo be true open source under LGPL - that would allow you 
  to piggyback on existing LGPL projects
[12:38] <Omnivore> and get feedback from other projects
[12:39] <EdorFaus> hmm I guess
[12:39] <Omnivore> you get more code review and debugging assistance that way
[12:39] <EdorFaus> but what parts do you mean should be kept semi-private then?
[12:39] <EdorFaus> yea
[12:40] <Omnivore> the core server side game code - think about what makes your game different from others of 
  the same general type - keep that part private but the lower level layers public
[12:40] <EdorFaus> hm ok..
[12:41] <EdorFaus> although depending on the game, it might be hard
[12:41] <Omnivore> so client server comm layer is open source, basic server internal comm and control would be 
  os - even the low level object model would be os
[12:41] <EdorFaus> yea
[12:42] <EdorFaus> former we had planned to do already, the latter two are more ambigous... 
[12:42] * EdorFaus isn't sure what exactly you mean by internal comm and control
[12:42] <Omnivore> if you guys can grasp it - I'd recommend building it atop my cpolib
[12:42] <EdorFaus> what does that do?
[12:43] <Omnivore> cpolib is a template toolkit library built atop the GNU Common-C++ lib - it's a fully 
  portable object serialization/streaming and object oriented database system
[12:44] <Omnivore> handles object reflection
[12:44] <EdorFaus> hm ok
[12:44] <Omnivore> so the program using it doesn't know/care whether objects are local or remote, in memory or 
  in the database
[12:44] <EdorFaus> hm nice
[12:45] <Omnivore> handles marshalling between different platforms
[12:46] <Omnivore> as to the other part - consider what *any* game server does
[12:46] <Omnivore> first of all it handles a number of player connections
[12:46] <Omnivore> authenticating players, connecting valid players to their proper internal game data, etc
[12:46] <EdorFaus> that's the client-server comm layer, right?
[12:46] <Omnivore> kind of the gateway to it
[12:47] <Omnivore> but yeah once authenticated it hands the connection off to the client/server comm layer
[12:48] <Omnivore> both authentication and game comm systems should sit atop a common comm layer - like what 
  cpolib can be used to construct
[12:49] <Omnivore> idea being to hide the complexity of lower level layers in a nice OO manner
[12:51] <EdorFaus> so.. when ppl connect, they first get to the auth system.. which takes pwd or whatever, and 
  compares with what's stored in an object(grabbed thru cpolib)... then, if match, somehow hands the connection 
  over to the comm system which takes care of the client-server comm and passes info thru the object(again thru 
  cpolib) to the rest of the game system... right?
[12:51] <Omnivore> yes
[12:52] <EdorFaus> I guess the handing over of the connection should be done via an object too... which, again, 
  would go thru cpolib
[12:53] <Omnivore> well think of it using remote method invocation with a player object residing partly on both 
  client and server
[12:53] <Omnivore> the connection belongs to the player object
[12:53] <Omnivore> the authentication system creates the player object, validates it, and then hands it off to 
  the game system
[12:54] <Omnivore> the connection goes along for the ride more or less
[12:54] <EdorFaus> k
[12:55] <EdorFaus> hm, and once the game system has the player object, it connects it to that player's data, 
  right?
[12:55] <Omnivore> now command and control issues get into, for example, the event handling subsystem in an 
  event driven game system model
[12:55] <Omnivore> *nod*
[12:56] <Omnivore> the server side player object acts as if the player was local to the server if you see what I 
  mean
[12:56] <EdorFaus> hm ok that way...
[12:57] <EdorFaus> iow, the cli-srv comm layer handles the comm between the client and the player object, which 
  then acts on the game as if the player was right there...
[12:57] <Omnivore> yep
[12:57] <Omnivore> your game code doesn't have to be concerned at all with client/server issues
[12:57] <EdorFaus> yea
[12:58] <Omnivore> another part of the server which could be open source is the very basic game object model and 
  event handling/messaging system
[12:59] <EdorFaus> hm, although I'm thinking of something... either the player object must always exist, or the 
  server must know when it doesn't and store the data somewhere for the object to grab later
[12:59] <Omnivore> eh player objects would be reflected to a cpolib created OODB
[13:00] <EdorFaus> ok, so to the server it would appear as if it was always there, while to the client it only 
  exists when a player is connected?
[13:00] <Omnivore> when a player first tries to login
[13:00] <Omnivore> yep
[13:01] <EdorFaus> k. then in a way it always exists... with the exception of being in memory or saved somewhere 
  for later reference
[13:01] <Omnivore> doesn't mean they'd always actually be in memory
[13:01] <Omnivore> *nod*
[13:01] <Omnivore> however done that way it is easy to send messages to a player who isn't currently logged in 
  for example
[13:02] <EdorFaus> yea... the "object" recieves the msg, stores it, and shows it to the player when zie connects
[13:02] <Omnivore> *nod*
[13:02] <EdorFaus> same way as if the player actually was connected at the time...
[13:02] <EdorFaus> ok.
[13:03] <Omnivore> only server side object that is 'aware' of presence/nonpresence is the message dispatcher
[13:03] <EdorFaus> ... which would be cpolib, right?
[13:04] <Omnivore> well would use cpolib - needs to be constructed to address the issues inherent to that 
  particular model
[13:04] <EdorFaus> ah ok...
[13:04] <Omnivore> think of cpolib as a toolkit - and extension to the C++ Standard Template Library
[13:04] <Omnivore> err an extension
[13:05] <EdorFaus> heh, that's what I read it as :P
[13:05] * EdorFaus notes that he doesn't have any experience at all yet with C/C++... so I don't really know 
  what the STL is, but I can guess
[13:06] <Mithandir> It's a drug for coders
[13:06] <Omnivore> if you design the game event/messaging system correctly you can, for example, fairly easily 
  have pluggable/scriptable AI
[13:06] <Mithandir> a lot like Acid, gives halucinations and sometimes bad trips
[13:06] <EdorFaus> heh
[13:06] <Omnivore> lol Mithandir, damn good allegory
[13:06] * Mithandir bows
[13:07] <Omnivore> I really wish cpolib was easier to understand but it is like STL in that respect, you really 
  need to understand C++ well especially C++ templates and the STL itself
[13:08] <Omnivore> the concepts are fairly straightforward but the implementation has to address a number of 
  thorny issues
[13:08] <EdorFaus> iow it's not just "pass it an object and it takes care of where it goes"? :P
[13:09] <Omnivore> oh it will once you create a proper system atop it - just not by default - way too many 
  variables for a general purpose solution at this point
[13:09] <EdorFaus> that's pretty much what I figured
[13:09] <Omnivore> for instance, in cpolib the OODB backend is abstracted
[13:10] <Omnivore> I do have a test example created using Berkley DB but you could use practically any backend
[13:10] <EdorFaus> hm, what exactly does abstracted mean in this context?
[13:10] * EdorFaus has a vague idea, but doesn't really know :P
[13:10] <Omnivore> cpolib specifies an interface to the backend
[13:10] <Omnivore> but does not implement it
[13:11] <Omnivore> it does implement a bunch of classes that can be used in such a backend and to ease interface 
  issues
[13:11] <EdorFaus> ah.. so you have to write a wrapper that takes care of the actual DB communication? it's made 
  so that it will tell a wrapper what to do and when, but can't really do it itself?
[13:12] <Omnivore> yep
[13:12] <Omnivore> an example:
[13:12] <Omnivore> typedef simple_unique_id< int32 > id_generator_type;
[13:12] <Omnivore> #include "simple_object2.h"
[13:12] <Omnivore> typedef data_mapper< marshal_2_type, id_generator_type > data_mapper_type;
[13:12] <Omnivore> class dummy_datastore :public data_mapper_type 
[13:12] <Omnivore> {
[13:13] <EdorFaus> well, in one way that's nice due to modularity and compatability, but in another it's not 
  since you must write that wrapper :P
[13:13] <Omnivore> that's the first part of the dummy test datastore definition
[13:13] <Omnivore> *nod*
[13:13] * EdorFaus tries to wrap his head around that piece of code
[13:14] <Omnivore> you have to choose the serialization method, the marshalling method, the id generator method, 
  and one or two other factors
[13:14] <EdorFaus> marshalling?
[13:14] <Omnivore> basically over the years I found myself writing and rewriting very similar code for each 
  seperate instance/combination - got old fast - hence cpolib - one system configurable to do all
[13:15] <EdorFaus> seems like quite a lot of libs come into existance that way :)
[13:15] <Omnivore> marshalling handles byte order and other interplatform information exchange
[13:15] <Omnivore> *nod*
[13:15] <EdorFaus> ah ok
[13:15] <Omnivore> I have two marshallers defined, others can be created and used with the system
[13:15] <Omnivore> the basic marshaller does no byte order processing - consider it a null marshaller
[13:16] <Omnivore> and a java byte order marshaller - uses the byte order/string handling defined by the Java 
  data input/output classes
[13:17] * EdorFaus thinks byte ordering as in multi-byte words on different processors
[13:17] <Omnivore> exactly - like the actual representation of a long when serialized byte by byte
[13:17] <EdorFaus> MSB or LSB first? that's the marshaller's thing, right?
[13:17] <Omnivore> *nod*
[13:17] <EdorFaus> ya
[13:17] <EdorFaus> and; serialization (basically=) how it's stored, right?
[13:18] <Omnivore> not to mention the possibility of machines that don't have 8 bit bytes or that have really 
  wierd integer byte orders
[13:18] <Omnivore> yeah how it is stored/transmitted
[13:18] <EdorFaus> yea
[13:19] <Omnivore> hmm I could give you a short primer on cpolib - it'd be easier to understand - it is actually 
  a simple system conceptually
[13:19] <EdorFaus> id generator - is that the always-unique player ID, or the temporary-unique connection id, 
  or..?
[13:20] <Omnivore> can be any type of id - but is used in cpolib's oodb toolkit to generate object ids so that 
  objects can be located in the back end datastore
[13:20] <EdorFaus> k
[13:20] <Omnivore> it seems simple - but consider id wraparound, id churn, multithreading, and distributed 
  server problems incurred in that topic
[13:21] <EdorFaus> I think I basically understand the system, really... basically, when you set it up right(with 
  what methods to use for serialization, marshalling, etc), you send it an object and it takes care of 
  storage/sending to the actual player/later access/etc
[13:21] <EdorFaus> hrh
[13:21] <EdorFaus> s/r/e/
[13:21] <Omnivore> in the application you're considering yes
[13:22] <Omnivore> first cpolib addresses the problem of dynamically createable objects
[13:22] <Omnivore> ie - creating an object given only the name of the object's class
[13:23] <Omnivore> so there is an entire subsystem that deals with those issues
[13:23] <Omnivore> then you have the serialization layer
[13:23] <Omnivore> which handles everything concerned with serializing an object to/from a stream
[13:24] <Omnivore> then you have the OODB layer
[13:24] <Omnivore> which addresses the problem of location transparency for objects
[13:25] <Omnivore> hmm skipped a layer
[13:25] <Omnivore> the object persistence layer
[13:25] <Omnivore> but you get the idea
[13:26] <EdorFaus> yea..
[13:27] <Omnivore> it basically handles a whole lot of low level stuff that you need without requiring you to 
  delve too deeply into the guts
[13:27] <EdorFaus> iow, it acts as a single layer to replace several intertwined layers
[13:27] <Omnivore> *nod*
[13:27] <EdorFaus> making your job all that much simpler
[13:28] <Omnivore> yep
[13:28] <Omnivore> hmm now if I could find my Valkyrie subsytem notes
[13:28] <EdorFaus> iow, to summarize what it is in a single word: it is a simplifier :)
[13:28] <Omnivore> hehe yeah
[13:29] <Omnivore> the Valkyrie subsystem design addresses the player connection issues and remote method 
  invocation model we were discussing earlier
[13:29] <EdorFaus> k
[13:29] <Omnivore> and I also have the notes for the Viking game server design
[13:29] <EdorFaus> hehe... the Valkyries are those loudly-singing women in operas, yes?
[13:30] <Omnivore> lol yep
[13:30] <Omnivore> messengers of the Norse gods
[13:30] <EdorFaus> iow, they take care of the communication(yelling) between the player and server :)
[13:30] <EdorFaus> s/server/game/
[13:30] <Omnivore> yep that's the idea
[13:30] <EdorFaus> nice naming :)
[13:31] <Omnivore> I had good drugs that day :)
[13:31] <EdorFaus> hehehe
[13:32] <Omnivore> not sure how applicable the Viking server notes are as they were for a more traditional 
  MMORPG server design - but they do address some issues regarding messaging, event handling, game object model, 
  and AI
[13:32] <Omnivore> sadly I think I deleted some of the information in a system purge awhile back
[13:32] <EdorFaus> hm
[13:33] <EdorFaus> ahwell...
[13:33] <EdorFaus> I guess I really should get some more experience with objects and programming anyway, before 
  I do something really big like this :P
[13:33] <EdorFaus> I mean, I've done objects. but not much.
[13:33] <Omnivore> conceptually though the idea is to handle all internal communcations as messaging - think of 
  it as windows for games, lol
[13:33] <EdorFaus> hehehe
[13:34] <Omnivore> you can then borrow an idea from robotics AI research and use a 'layered' AI approach which 
  sits right in the correct part of the message stream
[13:34] <EdorFaus> haven't got much experience in windows messaging programming either, I'm afraid... dabbled a 
  tiny little bit with it to communicate with winamp a while back, but not very much.
[13:34] <EdorFaus> heh
[13:35] <Omnivore> well a MMORPG or similar, regardless of the actual game, requires the solution to a number of 
  problems - not a bad area of research to aid in learning - but not an easy one
[13:36] <EdorFaus> heh I guess
[13:36] <Omnivore> if you just dive in and start coding or fail to do a thorough design process up front, you 
  end up with a mess - WorldForge is a fair example of that
[13:36] <EdorFaus> but I think I probably should get a little grip on the basics first
[13:37] <EdorFaus> heh
[13:37] <EdorFaus> never seen WorldForge...
[13:37] <Omnivore> *nod* well I'll probably be around when you're ready hehe, be glad to help out a bit
[13:38] <Omnivore> WF is a huge project with lofty goals - fully open source MMORPG system
[13:38] <EdorFaus> I guess it's a good thing both Kaelic and me have to get into school and start learning C++ 
  first, gives us a year or two to get through the planning/design stage :)
[13:38] <EdorFaus> k
[13:38] <Omnivore> unfortunately politics have gotten into the way of correct design and they've got a (imo) 
  crappy architecture to deal with and lots of internal problems
[13:39] <EdorFaus> politics gotten into the way?
[13:39] <Omnivore> any large project has internal politics
[13:39] <EdorFaus> k... still...
[13:40] <Omnivore> a small group of like minded individuals led by someone with a vision (however faulty) can 
  override everyone else
[13:40] <EdorFaus> that's *not* a good thing, when personal things get in the way of the common good
[13:40] <Omnivore> *nod*
[13:40] <EdorFaus> heh
[13:41] <EdorFaus> best to stick to a small group of like minded individuals then, and not go get ourselves into 
  big groups :)
[13:41] <Omnivore> basically the problem many open source projects run into (WF is not unique in this way) is 
  that they are started by eager individuals with a vision but who lack sufficient experience - problem with 
  many is that experienced individuals aren't welcome
[13:41] <EdorFaus> then at least we'll all agree :)
[13:41] <Omnivore> *nod*
[13:41] <EdorFaus> heh
[13:42] <EdorFaus> that's not good either, when they won't take advice by ppl more experienced than themselves
[13:43] <Omnivore> *nod* programmers are a breed who in general are very smart individuals - some have yet to 
  realize that just because they were the smartest in their own small rl community that they *aren't* 
  neccessarily the smartest in the global community
[13:43] <Omnivore> ego problems with young programmers are common
[13:44] <Omnivore> once you've been in the business solving real world problems for 10 or more years you realize 
  you not only don't know everything, but you don't even know half of what you thought you knew, lol
[13:44] <EdorFaus> hehe
[13:44] <EdorFaus> "wisdom is to know how little you know" -- don't remember who said it :P
[13:45] <EdorFaus> hmmm... I actually can't remember the last time I thought I knew everything...
[13:45] <Omnivore> yep - it's a tough line to walk for programmers - given the complexity and scope of some 
  problems we are asked to solve we have to 'pretend' for a time that we *do* know everything - otherwise we'd 
  never get the job done
[13:46] <EdorFaus> yea
[13:48] <Omnivore> too many people get into the field without realizing that they are getting themselves into a 
  situation where constant and continual study and training is a requirement
[13:49] <Omnivore> new techniques are constantly being invented, new libraries being released, new tools, new 
  environments - all of which require time and effort to become familiar with
[13:49] * Omnivore has allowed himself to fall a wee bit further behind on some of that than he should've

[<--] 28. April 2002 Up to game index page 27. June 2002 [-->]