• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

phiwer

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

133 Neutral

About phiwer

  • Rank
    Member
  1.   I found an implementation on codeproject which I'm using as a base for my server. So far performance seems ok.
  2.   It's a remake of an old game. It's not a FPS type of game, but a web based one.   I just thought it was an interesting read (the articles) and wanted to know if anyone had done any testing/experiments of how to develop a server with that method.
  3.   I'm with you on the details of the IO part, and yes the network layer for my game is probably not something I'll write on my own either way (I'd much rather focus on the game engine :) ). Any recommendations with regards to open source alternatives?   Just to clarify exactly how the game server/client will be used in practise: The game server won't be exposed directly to the players. The players will play the game on mobile devices and desktop web browsers (it's a browser based game). The front-end servers will in turn connect to the game server and then return result to player in either html or json (depending on device). In other words, the communication between the front-end and back-end need not handle authentication or be encrypted in any way (they are both on the same network behind a firewall).
  4.   I never suggested a thread/connection. Quite the contrary. The discussion is about the message passing (and work to be done with said message) after it has been received by the network layer. I'm merely inquiring about what experience other people have with this type of approach, or if a "standard" shared queue is the way to go.   I'll look into Akka.   Luckily I won't be using .NET on Mono. :)   /Philip
  5.   Thanks for the detailed explanation of your own results!   How would you solve the output/result issue with queues though?   We have one queue for the main thread, and one for output I presume? But would you have separate threads in the network layer that would only handle the output part, sleeping while no result is available? In this pipe-line approach the only thing bothering me is the output part.   I'd appreciate any ideas.   Thanks!
  6.   What you are suggesting is what I'm trying to remedy.   Your suggestion (or assumption) with a main thread and a lockless queue that each connection will post messages to might run into problems related to context switching. This is outlined in one of the articles I referenced. Another issue with this design is who returns the result to the client? You will most likely have another queue for this task, which will incur another context switch. I'm trying to get rid of these context switches by using the threads as workers, as recommended by the article. This design, however, might not conform to best practise (atleast not when seen from high cohesion/low coupling point of view..), but I'm trying to make the server as efficient as possible and am thus willing to make a few sacrifices for this.   I intend on using what you mention in your post (async), but the question is related to who actually makes the computation. Is it a dedicated thread (by your assumption) or should every thread that handles a connection take care of this themselves (to avoid context switches and data transfers among threads).   Thanks for the links!
  7. Hi,   I'm developing a game server for an online game, and I have some questions regarding how to handle threading from the network layer to the main loop. Some of the articles I have read regarding high performance servers actually raised the questions I'm about to ask. Here are the two articles if anyone is interested:   http://pl.atyp.us/content/tech/servers.html http://www.kegel.com/c10k.html#books   My main concern after reading these articles is the context switching. I've previously developed a prototype game server using python using microthreads/green threads to avoid context switches (to a large extent anyway). In this prototype I used two processes where they shared a msg queue. The network process would enter a message into the queue and then wait (its really one of the green threads waiting,..) for the game loop process to finish its processing. Once the game loop is finished it notifies the waiting green threads about the result (this has to be done, because the client expects a new state and a result from the previous operation). This sending of messages back and forth between processes/threads is one of the items the first articles discusses as a performance killer for servers. My question is now how to best remedy the situation when I'm developing the real server using C# 5.0.   The articles describes a way to remedy the situation of too many context switches by allowing the same thread that handles the incoming network connection to also take care of the processing and then send back result to client. In this model we may have say 10-15 threads (just a suggestion), waiting for a connection on the network side, once a connection has been established and message received, the thread turns into a worker. The worker then tries to aquire a lock (shared by the 10-15 network threads), and processes the message and sends back result. Afterwards the lock is released and the thread waits for next connection etc.   Does anyone have any experience with this kind of setup? Pros/Cons? One of the obvious pros is the ease of knowing who sender/receiver is as you're responsible for the current connection.   My goal is to be able to serve 50k messages/second. The game is not heavy when it comes to math, so the game loop won't have an issue crunching 50k messages/second. I'm more concerned with the network issue...   Thanks in advance!  
  8.   I think my point was just to reconsider whether it needs to be an entity (since it doesn't necessarily need lists of children buildings and players).   But if there are other attributes it has (such as... I dunno... name? population limit? ), then it can make sense to be an entity. In that case maybe I would have a VillageDescriptorComponent for the village entities (containing all the innate info about the village), and a VillageIdentifierComponent to identify things that are in that village (and perhaps the village entity itself would have one of these too).   What sorts of "innate village data" do you think would be part of a VillageDescriptorComponent?   Basically villages can fight one another, so some sort of track record would be needed (wins/losses etc). Also the current standing against other villages (bad standing/good standing etc), but this isn't really something that would be suitable for the VillageDescriptorComponent.
  9.   I would question the need for a "Village entity" ;-). What would this entity exist for?   "task of explaining that a player is present in a village"  -> I wouldn't make a different component for this. But I don't really know what this is. Is this a blob of text that pops up whenever a player enters a village?   No villages are more important than just describing if a player is present or not, that was why I thought they would make good entities. :)   Let's make the assumption that a village is something that ought to be an entity just for sake of argument. Then having a duplicate village component doesn't seem optimal, but if it's there only describe a position of the player, then I'd understand your point of not having it be an entity. Was this your point as well?
  10. You have the right idea, we just need to have the interfaces in the right place.   For this example, you can have the WorldComponent implement the IParent interface (it can be the parent of both villages and players), the VillageComponent implement both the IParent and IChild interfaces (it can be both the child of the world and a parent of players), and the PlayerComponent implement the IChild interface (it can be the child of both the world and villages).   You then create a ParentChildSystem which acts only on the components that implement these interfaces. Given a root object (such as the world or a village), you find all components on that entity which implement IParent. At the point, you then find all components across all entities that implement IChild, and reference any of the root object's IParent IDs. You then find all the IParent's on this new set of entities, and the IChild's on other entities that reference them, etc. It's basically a breadth-first search. Once you have the list of entities, the GoldSystem can find all the GoldComponents and tally them up, without concerning itself with parent/child relationships or hierarchy (since that's the ParenChildSystem's job).   The biggest downside here is that the generalized interfaces, combined with a lack of forward references from parent to child, can lead to objects being included that you didn't want, and rather inefficient searches (note the "all components across all entities" part of the search). The best way to fix this is to simply add the child IDs directly to the IParent component, and have the system keep the IParent and the IChild components in sync, as phil_t mentioned a few posts ago. It's still a BFS, except now you're not doing searches across all entities and components. This doesn't necessarily fix the pruning problem, where objects you don't want are returned in the search. As previously mentioned, there are different types of parent/child relationships, and you might only care about specific ones when doing certain searches. For instance, when counting gold, you probably don't want to consider objects that are just physically attached to the player or village, but perhaps objects that are actually "owned" by them. In that case, the interfaces can also expose what kind of relationship they are, and the search can prune them based on that.   If you want, you can also dispense with the interfaces altogether and have the GoldSystem know precisely which component types (i.e. WorldComponent, VillageComponent, PlayerComponent) it needs to query, as well as their exact relationships. For a small game this is the easiest approach, except you might find that some code gets duplicated as multiple systems end up querying the same parent/child hierarchies, since there is no interface type upon which to build a generalized solution.   Interesting articles!   And yes, searching in general when using an EC system seems to be one issue I will have to look into, if I want it to be handle many players. Thanks for the tips!
  11.   I like this approach as well, given that it "fits" entity/component better. I sometimes fall back into OOP thinking when modeling my entity/component system.   Would you share the same VillageComponent between Players and the actual Village entity, or would you suggest creating a different component with the sole task of explaining that a player is present in a village (e.g. PlayerInVillageComponent)?
  12. Let's take the case of gold as a component. Say you have a world of entities, and these entities in turn have some components which contain lists of entities.   To make this concrete (although a bit contrived):   World Entity (has WorldComponent)   WorldComponent in turn contains a list of Village Entities (has VillageComponent).   WorldComponent also has a list of Player Entities (has PlayComponent) that are out roaming the world but are not in villages.   VillageComponent also contains a list of Players, but these are specifically in villages.   There is also a GoldComponent, which each player has. Each village also has a GoldComponent (which the players can rob or such).   Now say I have a GoldSubsystem and there is a function GetTotalGold, which is suppose to compute all the gold for a specific entity and its children. So if I input a village I get all the gold in the village + all the gold of all the players. Nothing is static here, so sometime in the future I may decide to remove the GoldComponent from the village, but then I should still get the total gold of all the players in the village.   In this design, there must be some way of iterating through entities that are contained within components, and to query these if they contain specific components. This suggests that there should be an interface on the components to support this behaviour. Or am I modeling this wrong?
  13.   What persistence mechanism do you use when saving this component with lists of entities? NoSQL?     Hmm. Given that you have the parent/owner on the entity itself, why not store the children there too?
  14. If any of the states confer some sort of special logic in the LandComponent that only applies to that particular state, then they'd have to be hard-coded somewhere in order for the component's code to act on that state (option 1). Otherwise you'd need to make the logic data-driven as well, i.e. a scripting system of some sort, but that's another subject altogether.   The exception is if the logic of each state follows some similar form that can be coded in a generic way, i.e. each state just corresponds to a population capacity modifier, and the logic to transition states isn't specific to the current state. Then the states can be purely data because they're not tightly coupled to state-specific logic, and you can write a single piece of logic that knows how to set the population capacity modifier and transition states (basically, option 2).   True! I'll have to do futher analysis of this. As a first resort I think I'll go with option 1.   I've now started developing the component engine, and one question has come up. Although I don't want to do premature optimization I feel it's worthy of mentioning. I currently have a component called ChildEntityComponent, which is attached to entities that are children of some entity (e.g. Player has a lot of land). I've also developed a SubSystem for this component which many other subsystems will use, and as such it's important that it does fast lookup.   Some of the functions on this subsystem include: IsRoot, GetChildren, GetSiblings, GetParentEntity, GetRootEntity.   Right now there is only one way of traversing the relationship between entities (child to parent), so the GetChildren operation is expensive.   Does anyone have any good ideas for fast lookup of these operations? One idea I have is to let the ChildEntitySubSystem listen on events from the ChildEntityComponents and update a data structure for fast lookup for entities connected to one another. This encapsulates the knowledge of relationships between entities to the subsystem while still maintaining the overall component design (of parents not knowing directly about their children).   Any other suggestions?
  15. I wouldn't solve the issue of multiple systems modifying the same component value at the system design level, by only allowing one system access. One of the main reasons you completely isolate data and logic in this component design is to introduce a level of abstraction that allows the code structure to be independent from the data structure. However only letting one system modify a value couples the two structures together again and you lose the benefit of that abstraction.   Rather, I would solve the problem at the data level and use an approach that lets multiple systems modify a value in a well-defined way. You already touched upon such an approach with the various Modifier and Multiplier components. Generally speaking, you allow values to be backed by formulas, like x * A, (x + A) * B, etc., and allow systems to modify the inputs (A, B), whereas the constants (x) are sensible defaults or initial values. The formulas can have an arbitrary number of constants and inputs, and can vary per value depending on how you want systems to influence them. You don't necessarily have to implement such a system in the context of the component design, with individual components representing the various inputs and whatnot, since that seems as though it would get heavy with components for every input of every formula, and it's not really "game" code per se... however that's neither here nor there. The point is that systems aren't modifying raw values, but rather adjusting them in the context of modifiers/multipiers/bonues/etc., and you aren't gatekeeping them behind single systems. Best of both worlds.   Should the systems be responsible for state logic (hard coded), or would this better be put into the data section of a component based system? One situation is when a LandComponent is not yet finished constructing a building. During this time the LandComponent should have a different set of attributes compared to when it's finished.   To me it seems as if there are two ways here:   1) Predefine/hard-code the known states of Land (Developed, Constructing, Empty), and then let the SubSystem shift values depending on current state.   2) Define states in the data, and let the LandComponentSystem implement a state machine.   Any other way of doing this? Comments regarding my two suggestions?       An entity is a single building instance. What you're describing sounds like an entity to manage buildings, which could be the land entity (with a LandComponent) you mention later. However any given building instance wouldn't store the amount of its type. It would be redundant information on each building.   Yes ofcourse. I forgot about the LandComponent when first posting, and like you say a building is an entity connected to a LandComponent.