Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About @

  • Rank

Personal Information

  • Role
  • Interests
  1. You can divide your object types to several main categories, e.g. "NPCs", "PCs", "things", "boats" etc. All objects in a category has a lot in common, so avoiding those numerous if's, e.g. objects can be movable or not etc. Consider "things", they are world objects that can be placed in inventory etc. "Usage" can have some effects that can be stored as properties of recommended by hplus0603 "object type". E.g. object type "apple", "usage" will have effects: "energy" "+20" (+ maybe some others). When object instance is used, all its parent "object type" usage properties are enumerated and its effects are applied. it's a trade-off between more straightforward approaches and more universal ones advantage: still quite simple and straightforward disadvantage: still requires some amount of auxiliary code writing
  2. @

    Network API

    nice list is in forum FAQ:
  3. @

    async RPC

    now I see that I had to provide more details I'm trying to implement that "async RPC" for a game that already works on single zone server and has most of things you listed. also virtual world can be split to many zones and mobiles can move between zones. so now I'm on "interactions between zones" task. atm game objects interacts by stacking async calls. it was designed/implemented to simplify clustering support and to avoid many thread locks. and now I hope to transfer these async calls to that imaginary "async RPC". there're lots of such async calls and just implementing those pack/forward/receive/unpack methods doesn't look very pleasant. the volume of required effort allows experimenting. so "async RPC" is required for interzone communication. it's just a messaging system on low-level + high-level that allows to define "remote" methods as simple as possible and to concentrate on game logic instead of writing tons of low-level things. I'm familiar with DCOM and a bit with CORBA. Yeah, they are enterprise systems with all consequences. for example DCOM has many interesting approaches, but it was always resembling me a skeleton: strong enough but far away from complete body. it wasn't very convenient to use IDL to define COM interfaces but flexible. so I wonder what's better: to try to implement "async RPC" w/o code generation at all or to not bother about this and to write python script to generate required c++ code.
  4. MMORPG, seamless world split to zones, cpp there's intensive inter-zone communication, so the task is to simplify it's implementation as much as possible. I'm using "proxy" approach where a remote object is represented by its proxy in local zone. this proxy can communicate with its master. something like async RPC would be helpful, that allows to simply define "remote" methods and to generate as much code as possible, ideally it could look like: #define REMOVE_METHOD(return_type, method_name, args) where args are a list of method parameters (type, name, special serialization flag) this macro could generate: - declaration of [method_name]. definition will implement game logic that should be provided by a programmer of course - declaration and definition of forward_[method_name] that for a proxy will pack args to a specific type packet and send to its master - declaration and definition of do_[method_name] that checks if an object is master or proxy and calls its [method_name] or forward_[method_name] respectively - declaration and definition of receive_[method_name] that will be automatically called upon receiving specific packet, will unpack data and call [method_name] results if any can be sent back just like another remote method call having such system communicating with world objects would be uniform no matter where they are located and it would be extremely simple to add a new "remote" method, only specific serialization of some of its args can require additional effort (once per argument type) first of all, what do you think about this in general? are there any similar systems that can be used as a reference? there're two alternative ways to implement such "async RPC": - by macros: can be tricky even using boost preprocessor library - by code generation: e.g. by generating C++ code (pre-compile step) based on some simple syntax describing those "remote" methods what is better (more flexible or less time consuming)? any problems in outlook with code generation? tnx for your opinion
  5. Quote:Original post by Kylotan Quote:Original post by @ consider MMORPG. lobby (central) server keeps all client connections mainly to prevent logging in the same account. Of flip a flag in the database. There's no need for there to be one single server that holds every single connection. Checking for duplicate logins isn't a time-critical activity that can't afford a DB access. And you probably have to hit the DB to look up authentication/authorisation stuff anyway. looks like error-prone approach: client authorizes in lobby, lobby marks it as online in db and redirects it to zone server, client disconnects from lobby and crashes but is still marked as online one. the same happens when client moves between zones to prevent this a sophisticated check if client is really online is required, e.g. to check all zones if this client is really alive alternatively, to move a client ticket to zone server on redirection so it waits for this client and marks it offline in db when client haven't connected after some time. doesn't look robust too, timeouts are always a pain
  6. Quote:Original post by hplus0603 TCP has no such thing as "empty packets" because TCP is a stream. If there is no data to receive, then there is no notification. If you want packet semantics, you really want UDP, or perhaps (if you're adventurous and like the pain of early adoption), SCTP. tnx, bth I had to realize this myself. it looks like TCP keep alive would be the most efficient way to detect broken connections. i guess it's handled on kernel level. not sure about linux, but on windows going from kernel level to user one and back are pretty time and resource consuming moves. but as you guys suggested, I don't need to worry about performance, so will do it as regular one-way dummy packets from server to client
  7. is it possible by boost ASIO to receive empty payload TCP packet (keep-alive packet), just to update timestamp of the last client activity? tried: - boost::asio::async_read(socket, boost::asio::buffer((void*)0, 0), handler) - causes "end of file" immediately - boost::asio::async_read(socket, boost::asio::buffer((void*)0, 0), boost::asio::transfer_at_least(0), handler) - no "end of file" but handler is triggered immediately before any data was actually sent trying to avoid sending any dummy data with keep-alive packets, no need to measure round-trip delay to lobby server, cos it's measured to zone server
  8. what is the most effective way to detect broken connection? consider MMORPG. lobby (central) server keeps all client connections mainly to prevent logging in the same account. it should support thousands of clients. to support 1 min connection timeout it should send keep-alive packets every 30 secs to each client (cos almost all connections are idle). so having let's say 5K clients lobby will need to send keep alive packet every 6ms. sounds like a bottleneck. do i miss anything? is it more efficient to use TCP SO_KEEPALIVE instead of hand-made keep-alive packets? if I'll configure TCP keep alive options properly (let's say TCP_KEEPCNT = 1, TCP_KEEPINTVL = [any] and TCP_KEEPIDLE = 30), should I configure also any timeout to detect disconnection on 1 min timeout?
  9. do you already have working single server solution? if not first concentrate on it to attract enough people to load your server. as you already pointed yourself, your main server sounds like a bottleneck. alternative way is to connect clients directly to zones(regions in your terms) so you don't need to keep all these connections in main server. main server should manage only common data state that have to be synchronized between all zones, e.g. global chat or something else. the simplest possible case is to have single lobby/main server and many zone servers. you need huge userbase to have more then one main server in case it doesn't keep all client connections and is just a communication/synchronization center between regions. About seamless world: note that seamless world is quite complicated topic. if you already have working game logic you probably will have to make significant changes in your architecture/core implementation. If you don't have working game logic - read the first sentence of this post again :) yeah, sounds fine to connect client to the zone it is located in and to those adjusted zones that client is approaching. in opposite case you can generate a lot of useless traffic. just don't hardcode zone size too deeply cos probably you'll need to adjust it to the number of clients. two alternative approaches: 1) to have many small zones each one handled by separate process and possibly some of less loaded zones live on the same physical server. Seems to be a bit simpler to implement but can bring some important limitations in the future 2) to have configurable zone size. so single zone will live on single server. you'll be able to reconfigure your cluster to have highly populated zones handling smaller world regions also virtual world depends on your cluster configuration. consider big city or dungeon with frequent massive battles that is crossed by zones borders. even if you carefully implement your seamlessness this can bring you performance problems. tbh there're few discussions of seamless world implementation on this forum, and in general on web, so I would highly appreciate if somebody post some interesting links or share his opinion
  10. there was a discussion here: but I'd like to elaborate this topic. My logger uses TLS buffer for log-message formatting and std::ofstream for output. Buffering is disabled by std::ofstream::rdbuf()->pubsetbuf(0, 0). The question is: can I use std::ofstream::write() w/o locking? Locking is undesirable because logging is pretty intensive and this can reduce performance.
  11. our server starts to produce too many logs trying to write down every incoming and outgoing packet. what is a proven approach in this case? to log only important (rare) packets? to use more sophisticated logging? (network logging server?) to have all communication recorder is invaluable for problems diagnosis, especially on beta stage. what tradeoffs can community advise? tnx in advance
  12. great info, many thanks Quote:Original post by hplus0603 If you want to license it, I believe the current leader is Kynapse (recently bought by Autodesk), with PathEngine a good second choice. checked PathEngine (Kynapse's price is not published), 13K euros, it's quite expensive imho. maybe it's stupid question, but is this so difficult task that its 3rd-party solution is worth this money? Quote:Original post by oliii using inputs vs the client having semi-authority over his state is for security purpose. It's a lot easier to check a client input stream than his simulation results. I'm imagining this like: client performs complete simulation. if it sends inputs to server, server should constantly calculate all clients positions. taking into account several thousands of clients per server, isn't it an opportunity for optimization? sending pos update allows just saving it most time and only sometimes perform checks. And "pos updates" approach eliminates the need to send and apply server corrections completely, cos there aren't two simulations that at some point require synchronization. Quote:Original post by oliii If you want to let the client navigate by himself, and occasionally do sanity checks server-side, you will probably run into a large number of nasty exploits that will need fixing. yep, seems it's a trade-off, to implement maybe not so efficient but more reliable approach. taking into account a need to send and apply corrections, this approach looks like more labor-intensive too. at the beginning a MMORGG won't suffer of cheating, especially an indie MMORPG, first it should become quite popular. so this client movement checks on server-side can be implemented later, further simplifying "pos updates" approach. and why that server-side checks won't eliminate cheats? what do you think of this?
  13. fundamental answer, many thanks! walkable mesh sounds better cos it supports character movement verification and "navigation network" can be implemented later as performance optimization. but I'm quite confused. How to generate this mesh from terrain? Can this task be automated? semi-automated? how labor-intensive can it be? any 3rd-party solutions/tools? thanks again for your help
  14. [to oliii] thanks for detailed explanation. some questions: what is benefit of sending user inputs instead of character's pos updates? just cannot get this. client makes own simulation in any case, so it does collision detection. it can sends pos updates to server. server can take on trust received client po and just _occasionally_ check for client cheating. usually it won't perform any calculation simply storing new character pos. IMO the main difference between MMORPG and FPS is in server-side density of physics simulation. FPS needs dynamic collisions, shooting etc. so implementing own server-side physics for FPS becomes unreasonable and available 3rd-party engines provides fat benefit. But what is right for MMORPG when much simpler physics are required? or don't I see all challenges? multilayered heightmaps: i though exactly about multilayered approach. e.g. you have terrain grid with height's, some points can have values on different layers. when NPC's moving it checks difference between two adjacent points on his way. If they exceed some value NPC is blocked. will this approach work? also worrying if such heightmap generation won't be too complicated. does anybody heard about a 3d-party solutions for this?
  15. [to hplus0603's post] oh, no, I'm not going to implement own physics engine, at least not now ;) seems most MMOGs doesn't provide dynamic server-side collisions so it's not required for us too. all we need is simple server-side NPC terrain movement. as I said there're two options - to implement something from scratch, e.g. generate heightmap (multilayer heightmap to support caves, multistory buildings etc.) from terrain and to implement NPC walking according to it. Not as difficult as complete physics engine. And this can be done quite efficient, tuned just for this task. On the other hand, if 3rd-party physics engine can do it with the same efficiency and its integration will be easier then implementing that static collisions - why not? what engines gamedev's can recommend? I'm reviewing Bullet and ODE, rejected Havok (very expensive) and almost rejected PhysX (source code is very expensive).
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!