[12:29] 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] 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] that's sortof the plan, as far as I gathered... semi-open source, as in only show it to trusted ppl :P [12:38] 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] and get feedback from other projects [12:39] hmm I guess [12:39] you get more code review and debugging assistance that way [12:39] but what parts do you mean should be kept semi-private then? [12:39] yea [12:40] 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] hm ok.. [12:41] although depending on the game, it might be hard [12:41] 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] yea [12:42] 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] if you guys can grasp it - I'd recommend building it atop my cpolib [12:42] what does that do? [12:43] 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] handles object reflection [12:44] hm ok [12:44] so the program using it doesn't know/care whether objects are local or remote, in memory or in the database [12:44] hm nice [12:45] handles marshalling between different platforms [12:46] as to the other part - consider what *any* game server does [12:46] first of all it handles a number of player connections [12:46] authenticating players, connecting valid players to their proper internal game data, etc [12:46] that's the client-server comm layer, right? [12:46] kind of the gateway to it [12:47] but yeah once authenticated it hands the connection off to the client/server comm layer [12:48] both authentication and game comm systems should sit atop a common comm layer - like what cpolib can be used to construct [12:49] idea being to hide the complexity of lower level layers in a nice OO manner [12:51] 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] yes [12:52] I guess the handing over of the connection should be done via an object too... which, again, would go thru cpolib [12:53] well think of it using remote method invocation with a player object residing partly on both client and server [12:53] the connection belongs to the player object [12:53] the authentication system creates the player object, validates it, and then hands it off to the game system [12:54] the connection goes along for the ride more or less [12:54] k [12:55] hm, and once the game system has the player object, it connects it to that player's data, right? [12:55] now command and control issues get into, for example, the event handling subsystem in an event driven game system model [12:55] *nod* [12:56] the server side player object acts as if the player was local to the server if you see what I mean [12:56] hm ok that way... [12:57] 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] yep [12:57] your game code doesn't have to be concerned at all with client/server issues [12:57] yea [12:58] another part of the server which could be open source is the very basic game object model and event handling/messaging system [12:59] 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] eh player objects would be reflected to a cpolib created OODB [13:00] 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] when a player first tries to login [13:00] yep [13:01] k. then in a way it always exists... with the exception of being in memory or saved somewhere for later reference [13:01] doesn't mean they'd always actually be in memory [13:01] *nod* [13:01] however done that way it is easy to send messages to a player who isn't currently logged in for example [13:02] yea... the "object" recieves the msg, stores it, and shows it to the player when zie connects [13:02] *nod* [13:02] same way as if the player actually was connected at the time... [13:02] ok. [13:03] only server side object that is 'aware' of presence/nonpresence is the message dispatcher [13:03] ... which would be cpolib, right? [13:04] well would use cpolib - needs to be constructed to address the issues inherent to that particular model [13:04] ah ok... [13:04] think of cpolib as a toolkit - and extension to the C++ Standard Template Library [13:04] err an extension [13:05] 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] It's a drug for coders [13:06] if you design the game event/messaging system correctly you can, for example, fairly easily have pluggable/scriptable AI [13:06] a lot like Acid, gives halucinations and sometimes bad trips [13:06] heh [13:06] lol Mithandir, damn good allegory [13:06] * Mithandir bows [13:07] 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] the concepts are fairly straightforward but the implementation has to address a number of thorny issues [13:08] iow it's not just "pass it an object and it takes care of where it goes"? :P [13:09] 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] that's pretty much what I figured [13:09] for instance, in cpolib the OODB backend is abstracted [13:10] I do have a test example created using Berkley DB but you could use practically any backend [13:10] hm, what exactly does abstracted mean in this context? [13:10] * EdorFaus has a vague idea, but doesn't really know :P [13:10] cpolib specifies an interface to the backend [13:10] but does not implement it [13:11] it does implement a bunch of classes that can be used in such a backend and to ease interface issues [13:11] 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] yep [13:12] an example: [13:12] typedef simple_unique_id< int32 > id_generator_type; [13:12] #include "simple_object2.h" [13:12] typedef data_mapper< marshal_2_type, id_generator_type > data_mapper_type; [13:12] class dummy_datastore :public data_mapper_type [13:12] { [13:13] 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] that's the first part of the dummy test datastore definition [13:13] *nod* [13:13] * EdorFaus tries to wrap his head around that piece of code [13:14] you have to choose the serialization method, the marshalling method, the id generator method, and one or two other factors [13:14] marshalling? [13:14] 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] seems like quite a lot of libs come into existance that way :) [13:15] marshalling handles byte order and other interplatform information exchange [13:15] *nod* [13:15] ah ok [13:15] I have two marshallers defined, others can be created and used with the system [13:15] the basic marshaller does no byte order processing - consider it a null marshaller [13:16] 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] exactly - like the actual representation of a long when serialized byte by byte [13:17] MSB or LSB first? that's the marshaller's thing, right? [13:17] *nod* [13:17] ya [13:17] and; serialization (basically=) how it's stored, right? [13:18] not to mention the possibility of machines that don't have 8 bit bytes or that have really wierd integer byte orders [13:18] yeah how it is stored/transmitted [13:18] yea [13:19] 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] id generator - is that the always-unique player ID, or the temporary-unique connection id, or..? [13:20] 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] k [13:20] it seems simple - but consider id wraparound, id churn, multithreading, and distributed server problems incurred in that topic [13:21] 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] hrh [13:21] s/r/e/ [13:21] in the application you're considering yes [13:22] first cpolib addresses the problem of dynamically createable objects [13:22] ie - creating an object given only the name of the object's class [13:23] so there is an entire subsystem that deals with those issues [13:23] then you have the serialization layer [13:23] which handles everything concerned with serializing an object to/from a stream [13:24] then you have the OODB layer [13:24] which addresses the problem of location transparency for objects [13:25] hmm skipped a layer [13:25] the object persistence layer [13:25] but you get the idea [13:26] yea.. [13:27] 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] iow, it acts as a single layer to replace several intertwined layers [13:27] *nod* [13:27] making your job all that much simpler [13:28] yep [13:28] hmm now if I could find my Valkyrie subsytem notes [13:28] iow, to summarize what it is in a single word: it is a simplifier :) [13:28] hehe yeah [13:29] the Valkyrie subsystem design addresses the player connection issues and remote method invocation model we were discussing earlier [13:29] k [13:29] and I also have the notes for the Viking game server design [13:29] hehe... the Valkyries are those loudly-singing women in operas, yes? [13:30] lol yep [13:30] messengers of the Norse gods [13:30] iow, they take care of the communication(yelling) between the player and server :) [13:30] s/server/game/ [13:30] yep that's the idea [13:30] nice naming :) [13:31] I had good drugs that day :) [13:31] hehehe [13:32] 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] sadly I think I deleted some of the information in a system purge awhile back [13:32] hm [13:33] ahwell... [13:33] 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] I mean, I've done objects. but not much. [13:33] conceptually though the idea is to handle all internal communcations as messaging - think of it as windows for games, lol [13:33] hehehe [13:34] 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] 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] heh [13:35] 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] heh I guess [13:36] 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] but I think I probably should get a little grip on the basics first [13:37] heh [13:37] never seen WorldForge... [13:37] *nod* well I'll probably be around when you're ready hehe, be glad to help out a bit [13:38] WF is a huge project with lofty goals - fully open source MMORPG system [13:38] 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] k [13:38] 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] politics gotten into the way? [13:39] any large project has internal politics [13:39] k... still... [13:40] a small group of like minded individuals led by someone with a vision (however faulty) can override everyone else [13:40] that's *not* a good thing, when personal things get in the way of the common good [13:40] *nod* [13:40] heh [13:41] best to stick to a small group of like minded individuals then, and not go get ourselves into big groups :) [13:41] 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] then at least we'll all agree :) [13:41] *nod* [13:41] heh [13:42] that's not good either, when they won't take advice by ppl more experienced than themselves [13:43] *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] ego problems with young programmers are common [13:44] 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] hehe [13:44] "wisdom is to know how little you know" -- don't remember who said it :P [13:45] hmmm... I actually can't remember the last time I thought I knew everything... [13:45] 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] yea [13:48] 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] 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