• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

485 Neutral

About maunovaha

  • Rank

Personal Information

  1. I just backed Your Dream RPG - Make A Complete Role Playing Game In Unity on @Kickstarter https://t.co/VMRbQFgwFM #gamedev #unity #rpg
  2. If you want to make #website's, https://t.co/IntMTCTF2J is free and pretty useful resource for learning basics of #html & #css.
  3. Visited Oulu Game Day today. Pretty cool to see fellow developers live and try out their games. Feedback is invaluable. ?? #oulu #gameday
  4. Thanks braindigitalis, it was interesting read. :)   I think I have started to see some patterns here regarding the requirements - which is good. Also, I forgot to mention earlier that my plan is not to do detailed explanation of client-side things, because I am mostly interested in documenting the server-side parts. For this reason, things like "client-side prediction" are outside the scope of my study and how / what should be predicted is really game dependent anyway. Nevertheless, I like the information already provided here and I think I have enough for now. Thus, my C++ skills are too poor to interpret your awesome code. But thanks for the offer.  :D
  5. MMOG Optimizations

    Interesting write-up, thanks for sharing it. I have few questions thought.     Q1: Did you measure how much this optimisation affects cpu and bandwidth usage? I assume that this was done to drop bandwidth usage, but I would imagine that it increases the calculation complexity, but I guess it is cheaper if your game server can still respond on time regarding the game update rate, and should be done like this? I had thought that typical method of implementing this is just to use e.g. circle AOI to detect the zones player should receive updates from and not to fine tune it to loop over the area of AOI any further. But I guess in these cases the size of the zones matters as well?   Q2: Do you use some kind of delta updates? or when does the players receive full information of a new player entering to a zone?   Q3: Do you have one general game loop at the server which is sending (world updates mentioned above) and then separate message transfers which are only meant to individual players? e.g. if I buy item from a shop I receive response for that from the same server and it has nothing to do with the world updates.     Q4: How do manage the processes when the game server goes live or offline? if your game server is made up of multiple processes (maps) which can be shared between computers, I would suspect that discovery and management of these could be difficult?
  6. Thanks for the replies, they were really helpful.   In summary, using of postgres with json column sounds good - so I can skip using of MongoDB - and I plan on modifying my study to be more like "high level thing" than "game details specific", the reason for this is that like you mentioned that the final architecture will emerge from the game design -- which is most likely true -- but I don't have room nor time for making detailed e.g. "20 pages GDD" within the study and evaluate it. However, I won't go too high in a way that there is no way to validate anything in a reasonable manner (hey, this is "yet another client-server architecture you can build anything upon" ... mmkay?). Hence, part the of study is to build/evaluate in practice so that is something I am planning to do. Luckily there is a lot to learn from that. But yea, thanks again for the help! :cool:
  7. Sometimes I feel that writing #css without google is like eating a soup without spoon. Who invents these things? Oh yeah, us...
  8.   I think a lot of the RPGs shares same set of functionalities - those are the ones which makes them "RPG".. if you would compare World Of Warcraft, Silkroad and alike, you can see that those all has an ability to create your own character and explore magical world through quests, combat and collaboration with fellow players, there is NPCs, shops, items, leveling.. etc. I am not saying that every game fits - or should fit - this model, I just want to set some common features which should be taken into account within the design of architecture. After that, I document that these are the type of RPGs the architecture is intended to support. But I agree, it gets easily too application-specific if I am not careful and the level of detail I finally take into account is a problem of my own :P For instance, quests like you mentioned might be something I should not care that much or "evaluate" because they are only a typical feature within the game. On the other hand, implementing of authentication, registration and chat might need different services from the architecture.. and they are important enough to spend time to document.   In summary, I posted this question to find out whether I am missing something huge and get feedback :).. that said, if I would design architecture based on your a) and b) it already lacks information I would like to document.. (registration, authentication).. and btw, those are the very reasons I am doing the current work. I think 90% of the previous research states that "authentication is outside the scope of this paper" and only focuses to the communication between the game client and the game server. But we all know that proper MMORPG needs more services than that to function - and that is the information I would like to bring into the mix. And the reason I am not doing architecture for just all MMOs is that MMOFPS and MMORPG would typically have very different kind of latency requirements which means the fight between using of TCP or UDP.
  9. Where I come from, friends don't let friends use Mongo. You should look really hard at alternatives, such as Cassandra, or Redis, or SimpleDB, before you actually go down that route.   hehe.. well, I have used MongoDB before for game data (only a demo game) and for data regarding a web service (only 700 - 900 users online at once but about 200K registered, if I recall correctly) - maybe I haven't spend too much time with it as I didn't find any good reasons to not to use it.   Anyway, I guess there is not much to store when it comes to game data .. things which I had planned to store to mongo are the location of a player (x, y) and items he posses (backpack and bank), experience, level and alike. Basically only the relevant info which he needs when he logs in to the server.. then after that a lot of the data (like location of NPC) will be in-RAM (as you said).    I had planned that game saving will be done in patches, meaning that I will pick up the relevant game state information (regarding players) from ram using a fixed interval and save it  to database. This way I am not trying to save the game on every tick as I suspect that the database load will increase dramatically.. but if I do it like this only, I guess in the case of server crash players would lose the items they have received from rare bosses too.. doesn't sound awesome, but it would be same for everyone -- sounds fair?    Nevertheless, are you saying that replacing MongoDB with Redis is completely fine? and I can load the player state from Redis the same way I load it from the MongoDB when the client connects to the server? I haven't used Redis before, but I thought that it is not a persisted storage for data.
  10. Hi,   Thanks for the good points - as always - your post actually gave me some more things to consider.  :)   And you are right about difficulty of finding the middle ground, I feel dizzy every time I have to think about it.. but I am willing to give it my best shot; I am extremely happy if I come up with a solution which seems to have all common pieces in place and doesn't go too deep regarding the details.   That said, your comments made me think that I should emphasize that I am designing architecture for browser-based real-time MMORPGs and type of the world it should support is a mirrored world approach. I have read that continuous world and server-to-server communications requires very different things from the underlying architecture.. and yes, I have had plans of using Postgres for account information etc., plus MongoDB for the game data.   Nevertheless, I think I am starting to see the big picture now, but because designing architecture and validating it is a whole different thing, I guess I have some problems further down the road.. but that is already a topic of its own and I will post it later if I see it necessary. But thanks!
  11. Hi,   I am in the middle of the process of designing browser-based MMORPG architecture and I am trying to define a generic set of functionalities which these kind of games typically needs. Hence, the challenge here is that these features or aspects should not be defined specific to some game - they should be applicable across typical MMORPGs. The games I am referring to are the likes of World of Warcraft and Silkroad Online, etc. Thus, I am very well aware that task I am doing is big -- but I am not trying to implement MMORPG from scratch here, I am simply trying to come up with an architecture proposal which is larger in content than many of the previously written articles, as they typically describes only the communication between the game client and the server and skips the issues raised around authentication / security and alike.   That said, I already went through the material regarding previously designed architectures and I conclude that non-functional requirement of "scalability" seems to be the deciding factor in MMORPG development.. and the latency, bandwidth and cpu usage basically makes developing these games remarkably hard and affects the scalability aspect of the game. However, there are also other things which I identified, and the initial list is here below:   Functional requirements: Authentication Registration Character creation/loading Game loading/saving Game state calculation/distribution Chat Quests Fighting Movement NPCs Non-functional requirements (high-level overview): Security Reliability Scalability Availability Traceability Maintainability Usability The way I am planning to use this knowledge is to find things which should be documented within the architecture and to be part of the architecture... the evaluation of the architecture is another thing -- for instance, it is very unlikely that I implement an MMORPG to test that it satisfies _all_ the requirements, I simply don't have time to do that. But I will come up a way of evaluation things once I get there.   But now, any comments will help, thank you!   Edit:   Realized that my "functional requirements" are more like "features" but nevertheless I think the goal of this post is still clear. I am planning to format them properly withing the actual work.. same applies for strict limits of non-functional requirements.
  12. Type of "questions" at #stackoverflow is getting ridiculous.. Some people are posting links to their live site and say "go debug it" :D
  13. Life goal: Explain your job as a #programmer to your parents in a way that they understand what the hell you are doing.
  • Advertisement