• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

882 Good

1 Follower

About Valoo

  • Rank

Personal Information

  • Interests
  1. My situation probably leans more towards the bad/convoluted code wasting cycles scenario. But okay, i think i have a good amount of information now, thanks for the input.
  2. What i meant was the runtime location of player related data. Is it common to have it reside partially in multiple locations; If the services are physically or logically separated, how do they access the same resource, does each load/gets assigned its part of the dataset (maybe just passed along at the point of a request?), or am i approaching a problem from the wrong side? It seems to me that this may be vital in my understanding of 'distributed' (realtime) computing.
  3. That sounds plausible. And for the player data splitting, is it a bad idea, or too dependend on specifics, is there a common route i can take or terminologies i can look up to learn?
  4. Yes, i think some delay here and there will most likely not be a problem for this type of game. I'm not sure i understand what you mean by multi-database though. If this targeted the split player data question, i was under the impression that even for this distributed design i'd still only need one database, but what i was wondering about was, if on login, i should just load, from the db, the player data in parts for each server (i.e. zoneserver receives the realtime-relevant part (transform, skills etc), whereas the world/gameserver the non-time-critical parts (inventory, friendslist etc.) for example. It feels like this could be a setup for headaches, especially if some things have both realtime and non-realtime components (like droppable items/with spells). What would be a common way to go about this, hold everything on a zoneserver and supply the other services with the relevant data only at the time of a request? (this sounds like more load on a zoneserver and more roundtrips for messages)
  5. That already answers a lot of questions, thanks. About the persistence part: My naîve understanding of persistence until now was that the gameserver (or serviceserver) runs a recurring timer that just updates the database with newly piled up changes, but your description sounds like i should handle all corresponding changes (even moving items in an inventory) as transactions with the database where i only let that change apply to the active, simulated data if that transaction succeeded (and not the other way round - updating the db state after it registered as a change in the simulation)? My guess is that this would create longer response times and that the load on the database goes up. But i haven't tested this, so i may just be overreacting here. When you say 'Ephemeral state', does that mean the player data may indeed be split between the servers and a zoneserver only holds the part it needs for its simulation (as in, the inventory items for example are kept on the gameserver as trading etc are handled by one of its services)? A trading request from one player to another would mean, if they are only able to do so in a certain distance to each other, that the gameserver/trading service must hold some positional data too, or should it just query the zoneservers in that case; how to go about this shared data? (I'm thinking that such a request should not need to pass through the gameserver just to become a request from the zoneserver back to the gameserver/its services, meaning in my imagination it should be able to somehow directly be handled by the former, to cut some internal roundtrip time)
  6. Hi, i am trying to find a good (server) architecture and some implementation hints for my indie multiplayer game i'm designing. I have previously worked on as small scale restoration project for an old mmorpg. The intend was not to have thousands of players connect, but to provide a manageable amount of players with a consistent view of the world; with this goal in mind, and because of not having much practical experience in designing such systems, it became a monolithic server that clients directly connected to. It turned out though that the biggest bottleneck was the simulation of thousands of npcs (active regions increasing on players spreading). For my current/own project (a space-sim kind of game) i intend to have similar requirements: small amounts of players (10-100 max), but big amounts of npcs (thousands, moving along paths most of the time, but observing their environment), a basic physics system (mostly queries, no complex simulation), indirect (chat, trading), and direct/spatial interactions (some form of combat) between players and npcs (trading, conversations, some form of combat). Apart from that, i need to be able to implement changes to the game design without too many cascading steps (some of the interactions are not yet mapped out completely). So, trying to learn from the previous project, i now want to find a better architecture for the systems involved in handling this. Having mostly worked with unity before, my basic way of thinking is in loops (or synchronous events), but the more i read about the different server designs, the more i see asynchronous messaging between distributed systems as a way to tackle such problems. I found valuable resources on 'Engines of Delight', but most of them seem to target the challenge of high amounts of players/connections or just a bigger scope in general, so some of their parts 'feel' unnecessary for my goal (a frontend server for example). But splitting the systems into interconnected, and the game world into separately simulated zones, seems like a way to go (with which i have no experience yet, unfortunately). So my questions are: If i intend to separate the game systems, is this reasonable (amount of work/benefits, 'secure enough', iteration-friendly)? : Authserver (login, version check) - public Gameserver (zone management/character transfer, message relay, persistence(DB saving/loading)) - public Zoneservers[] (physics, gameplay, ai, chat? etc) - internal And if so, the questions i'd have were: where does the character data (players/npcs) live (gameserver, zoneserver); do i send relevant data back and forth between them (each has a sliced copy of the data only covering their concerns) or do they each own a synced full copy for easier cross-system communication / zone transfer? Or are there alternative or even better solutions for my requirements?
  7. Depending on the situation, you maybe could get away with simulating gravity and only interpolating the horizontal movement. I have no idea if this is true, but Guild wars 2 feels like it does this for proxy player characters (with occasional corrections).
  8. 12 weights, one is different

    I didn't read any of the above answers, maybe it's already in there, but i think this works:   [spoiler] weight 6 vs 6 if one is heavier, split that into 3 vs 3 split the heavier one into 1/1 and take one away. if the remaining two are equal, it's the one taken away, else the heavier one. [/spoiler]
  9. I know that it has to be specific to the game, and i hoped to build a system that becomes specialized at the point where the user created his game specific requirements (and/or implemented the associated (generic?)interfaces for the entities). I currently also have a kind of trigger system, not as sophisticated, but involved entities (npc, player, world context) can be notified when a dialog option is selected. AND'ing and OR'ing of the requirements is also already in there. It's just the way the requirement is structured that currently botheres me. But i will see what i can do with all the suggestions i got.
  10. I understand now, thank you for these suggestions.
  11. @Alberth The idea of passing check objects sounds good. I guess that would mean i still keep the base requirement class with the valuetype fields which the specific check object then takes the ones it needs from, kind of like an adapter?   @Servant of the Lord For the strings idea, it seems to me that this means logging all game events in this string format. And that means checking the inventory for example for an item would become a search for "PickedUpItemX" or the surrounding system has to know which specific events to log as a certain keyword which i feel could be a too strong requirement for the system. And to your script idea it sounds to me like you mean it in a similar way to these check objects, no? (if i understood these correctly)
  12. I see, my explanation wasn't that good and it seems missing some information. Each entity that needs dialogs has the dialog component that holds all dialogs for that entity. If the player requests dialogs, the code checks the each root element of the dialogs for its requirements. This means, foreach DialogRoot (and subsequent dialogoptions: if at that point), i pass the dialogrequirements to the entity the req. is targeted at, for it to check them, because i currently have no idea how to kind of externalize them (i hope that word describes it better). In the end, i want to enable the user to create custom requirements specific to his game (and maybe the validation methods, if those are needed?), for example like Requirement_HasItem that i can use in my system without hardcoding them or having a big allround requirement class with all value types as fields and an enum that defines how the values should be handled (what i currently have)
  13. Hi, i'm writing a dialog system (first serious attempt) and came to a point where i want to make it more 'unspecific'. Each dialog currently has options to specify requirements (List of DialogRequirement objects) for it to be a selectable option, which consist of a target (enum - npc, player, world) and a type (enum -state, logEntry, etc) and a few value fields (int, float, string). When checking the requirements i select the target based on the enum value and pass the requirement object to it. Targets implement an interface (IDialogRelevant) with bool ValidateRequirement(DialogRequirement) and use the value fields for the check. The problem i have is that the requirement has these value fields (int intValue, float floatValue ..) that are bad to read and easy to implement wrong in the DialogRelevant entity and also the RequirementType enum too tied to a specific type of game (the requirementType enum currently has things like QuestLog for example).   What i would want is it to be extensible , like new requirement (sub)classes which then could (and should) be more specific. What i thought, but am confused about is generic interfaces, or an abstract generic baseclass. (But if, how would i 'connect' these to the specific requirement target and pass the required value and what way should i do it, and wouldn't i have to typecheck and cast these before passing them to the specific target as i have to store them in a baseclass type field?)   i'm using unity (c#) and already have a visual interface ready to build the dialogs, but want it to be open to the requirement types that the user can implement, like i think giving them a Draw() method would be the way (as there's currently only this one requirement object i just inlined the drawing of it).   How would i design it?   I hope you can understand what i mean.
  • Advertisement