Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

285 Neutral

About detlion1643

  • Rank

Personal Information

  • Role
  • Interests
  1. So I really was overthinking it and trying to solve a problem that doesn't exist? I was thinking since it's coded, we could make it more defined with card having its own separate chance of being pulled. But now that it's explained, that wouldn't work as the number of cards in the entire pool keeps changing. It is simple to create the rarity category system and tag cards with their category. Then, I'd roll the random, see what category I need, and pull a random card from that category. Thanks for the input.
  2. I am currently designing and coding up a general card game. I have developed enough server and database code to have a complete register/login system working and also have everything set up the database for modular building of cards. This is all great and working, and now I come to the point where I have to create "packs" of cards. I don't understand how to implement the "percentage of getting a card" type of system. I was originally thinking that I can tag each card in the database with a percentage of being acquired, so that I can fine tune each and every single card if the need ever arises. So, let's say that card1 has a 1% chance of being pulled and card2 has a 100% chance of being pulled. With this setup, if I use the normal random methods Random _random = new Random(); //this is class level declaration //create a pack here of 5 cards double percentageToPull = _random.NextDouble() * 100; Now, let's assume percentageToPull becomes 55%, we should never pull a card below that 55%. But, if percentageToPull becomes .9, we now have a chance at pulling that 1% card. However, in my mind there is also that 100% card sitting there. So I can't assume the lower percentage pulls are guaranteed (.9 != 1), and if I look at cards >= .9, it's now another rng on top of rng. However, on the other side is how most games are set up now. They set up "rarity levels" of their cards. Cards 1-3 are "common", card 4 is "uncommon", etc... So when creating a pack we can guarantee pulling any card within any rarity level. Both systems create a random aspect of creating packs of cards to be pulled. However each system works different. I like the idea of having control over each individual cards "chance" of being pulled, but if creates this much difficulty, i'll go with the more standardized rarity level system. Any thoughts/opinions?
  3. Thank you so much for the explanation! I do have a domain, a free one for testing, with no-ip and their dynamic client so I can run the "server" on my laptop and have outside clients connect to it.
  4. Session checking, type checking, load balancing, etc are good points, but not relegated to only game loop driven servers. I haven't done any web based programming before, just some knowledge of asp/HTML/JavaScript. If going to an https route won't I need a domain and create the page(s) to do everything?
  5. I'm pretty new to the game side of things. However, I built up a pretty solid generic server/client framework using c#. When I mean generic, I mean very generic. Basically with a few lines of code you can make a server, where all the meat is done via subscribing to the server events (connections, messages, etc, etc)... That got me thinking of how I might network a game using this idea. I'm more into the casual environment of things like card games. Specially ccg's/tcg's. These types of games are not physics demanding, but still can be networked so users can play against others. All messages get converted to a byte array upon being sent over the network, be it from client or from server. So I ventured out and created a little test where the client can send "messages" to the server. Let's say we want to login, it might look like this: client.Send(new GenericMessage("Login", new object[] { "Email", "password" })); So we can just have clients send their "actions", where the server will do the validation of said "actions" and either do nothing or perform whatever it needs to do. By this theory, when I think of the ccg/tcg idea, we can make "actions" like "DrawCard", "MoveCard", "PlayCard", "Attack", etc... Clients can send whatever they want whenever they want, as mentioned the validation would be done server side. The whole reason for this post though, is when I think about it, it might be a complete waste of time, because the server side isn't running a "game loop". The clients would be, as they could be theoretically programmed in any language. Is there any reason this is a bad design for a non physics, non realtime demanding game?
  6. I know that this isn't the way to be testing this, but I put in an integer counter and stopwatch. Every frame adds 1 to the counter and when the stopwatch elapses >= 1000 milliseconds, I reset the counter.   I spawned 1000 quads, each rendered with it's own Begin/End. The counter averaged between 25-30. I'm assuming this is equal to 1000 draw calls.   I then spawned 1000 quads into 1 VBO. The VBO now consists of an array of 4000 Vertex (a class that just holds X, Y, Z floats). The counter averaged between 75-80. I'm assuming this is equal to just 1 draw call.   I guess the increase in performance is nice to have. I'm just now concerned on how to go about modifying the individual pieces of the massive VBO array.   Previously, with the single Begin/End for each object, I could move (translate), rotate, color, etc each object individually as I see fit.   Now with using a VBO, I have mapped each object (which now contains a Guid on creation) to it's corresponding index entries in the massive array. So, at least now I can control the positioning of the objects (translating) individually. This just updates the entries for that object in the VBO array.   I've got some thinking and trial and error'ing to do about how to go about controlling individual rotations/scalings. For colors I have done some reading about creating another array to hold the color values for each piece. That seems about the same as the individual positions though.   Hopefully I am still on the right track...
  7. I'm just not sure yet. The plan is to make it fully dynamic. That just gives me options from the start if I ever need them - changing the vertices, colors, etc.   It sounds like how I imagined would work then. I just need a way to keep track of which button (or class/control) corresponds to which set of vertices in the VBO.
  8. Think of using this "design" more so from a software standpoint than a game and I hope it makes more sense.   I've been currently dabbling in OpenTK/OpenGL. I've created a class that represents a 2d rectangle, it is called a button. So, when a user instantiates a button, they can define any top/left/width/height locations and also a color. These can be changed at any time, so for my very first initial test, I just used the normal glBegin ... glEnd methods to render each button. For now it works, however I am not satisfied.   So I started reading/testing stuff about VBO's. From what I understand we don't want to make a VBO per object, so the idea of making 1 VBO per button is not ideal. This is the easiest start of VBO's for me though. I already did this as a quick test and it seemed to help performance a little bit, although I am still very underwhelmed. I understand that the constant switching of the binding buffer "per object" is the biggest downfall of this implementation.   Now that leaves me with an understanding that we should minimize the number of VBO's in total so the amount of switching the binding buffers is minimal. The understanding of this is what escapes me...   Buttons are just a start and they are predefined with 4 vertices (an array[3] of vertex - another quick class that holds x, y, z floats). The plan is too keep adding more classes that users can use (labels, lists, etc). These can then drawn in any fashion, not being forced into only 4 vertices "per control"...   I was thinking that anything with 4 vertices would go in 1 VBO, anything with 5 vertices in another, and so on... This way we only make new VBO's when they are needed, otherwise if something can fit into an already made VBO, we can add it there.   So, if someone renders a test of 100 buttons and 1 triangle, I will need 2 VBO's (100 buttons in 1 VBO and 1 triangle in the other VBO). Then the calls to draw 101 total objects is only 2 (1 per VBO).   Does this sound reasonable with how VBO's work? Or is there something else I should know or be doing?   P.S. - "Buttons" are my first class to me made, and there will exist both 2d and 3d stuff...
  9. detlion1643

    Multiple server architecture

    Thanks for the information everyone!   I am currently well on my way of starting a shared framework for the servers. This will make it easy so that I just have to reference the library and supply an IP and Port to open up a listener to connect to. The first server I am working on is the login server. The plan is to have a direct connection to the database rather than go through a database server. It'll allow account creation and logging in. After a successful login, it will send the client a message to connect to the main server (which I'll work on after the login).   I'm also currently working up another shared framework that both the servers and clients use. This houses all the network aspects (connections, reading, and writing). So, using this, the client will connect to the login server IP first, and after receiving a successful login message, will reconnect to the main server. The framework makes it easy to pass in an IP and Port to handle all the work. The client can then listen for incoming messages or send messages to the server using the framework.   I would like to reiterate that this is not an MMO project or anything on a huge scale. The idea is to just build up the servers so they can be scalable, whether adding or removing to balance out the players that are connected.
  10. detlion1643

    Multiple server architecture

    It's a tcg/ccg action game. It's not a 3d seamless world, but rather lots of small "pvp like" battles. It's not really player-hosted either as the games will be "played out" on the server for authoritative decisions with the clients just sending input, but yes, there will be a matchmaking service. Also, I have plans that this server architecture/design will be helpful in more than just this project.   I have lots of ideas now on how to go about this so thanks everyone for getting the wheels turning!
  11. detlion1643

    Multiple server architecture

    All the information is great!   It sounds like I will be opting for a Login, Main, Database and Chat constant servers, then a variable number of Game Servers.   The client connects to the Login server which checks authorization within the database and tells the client to connect to the main server. The main server does the "load balancing" by deciding what Game server the client should connect to. The client then connects to the game server.   Now, is it feasible to have the game servers connect to the chat server? So the client could send a message to the game server with chat information and the game server sends that along to the chat server rather than having the client handle the separate game/chat connections.   I'll have to ponder over this and come up with some new designs to lay out.
  12. detlion1643

    Multiple server architecture

    Sure, there are lots of better ways to do look ups than just using a loop on a list per-say. However, the logic is still the same, find the server we need to send to...   Spinningcubes, thanks for those links, they were great!   So it sounds like the game servers should access the database directly.   Chat messages are just an example. But if client 1 writes a message to the database for client 2, how would client 2 know there are new messages? It doesn't seem feasible for client 2 to poll the database constantly looking for these. That means all clients connected would be polling the database for just messages, constantly. I can certainly see the use of the database in the chat example, as then all messages are streamlined, in order, and can be received by the clients in the same order.   I do like the idea of having a separate Login and Main server though. I'm unsure about the "handoff" or if the client would just handle the connection stuff. Being C# I can't serialize the TCP classes, or classes that use the TCP classes.
  13. I've been currently building a server using C#. I've also been building a test client in Unity. I am familiar with C# and this was the quickest/easiest way for me to get something working. I am currently using a custom message class that is serialized to do communications between the two. While everything does work, I keep rethinking my design, and as of right now, I am contemplating scalability. I'm currently using the .Net TCP classes for the networking.   To start, it's just 1 server running on my laptop (for testing) using No-IP so I can connect from the outside world. Once connected, the server/client can send my custom message class back/forth depending on what each other is doing or wants to do. Then I started thinking (that's never good) that I don't really want to rewrite anything for expandability. I'm not really thinking that the game will go anywhere or get high numbers, so I know that I shouldn't think about this, I just keep coming back to it so I can do it "right" from the start.   The reasoning is because I can reuse the design in other projects. So I started making a sketch of how I think the flow would go with 1 Main/Login server and multiple "spin up servers". The client would initially connect to the main/login server. Upon a successful login, the client would drop that connection and connect to one of the "spin up servers" (identified by the main/login server telling it which one to connect to). Now, all client communication would go to the "spin up server".   But now I rely on the client negotiating connections which can be problematic. But I don't think we can solve this as the client needs to connect to a new IP/Port. Now, the "spin up server" would act like my server which is already coded because the client can only interact with it.   The spin up servers always maintain a connection the main/login server so they can communicate. Thus, we can code in logic to do cross-spin up server communication by sending messages through the main/login server.   So if client 1 on spin up server 1 wanted to send a message to client 2 connected to spin up server 2, the relay would be something like this: - client 1 -> spin up server 1 (send message to client 2) - spin up server 1 -> loops all its clients (it can't find client 2) - spin up server 1 -> main/login server (send message to client 2) - main/login server -> loops all clients (from all spin up servers) -> finds client 2 - main/login server -> spin up server 2 (send message to client 2) - spin up server 2 -> client 2 (here is your message)   This just seems abnormally bloated, especially if we start having lots of cross server communication. Is this really the right way to go about multiple servers though? To be fair, I ideally will only start with 1 spin up server. It's just for future proofing and as a concept that can be used on other projects.   Also, might as well mention that the current game idea is a tcg/ccg. So it's not as real time as an MMO or action combat game. Of course, to stay synchronized across all servers, only the main/login server would have access to the database (I think).   At this point I am currently wondering if this is right at all? Are there any suggestions? Warnings? Etc, I'll take any advice on the matter...   P.S. I have read tons of threads on the forums, but I don't recall going into much detail. I have also read this [url="http://dl.ifip.org/db/conf/iwec/icec2006/LimCKS06.pdf"][Dynamic Load Balancing for MMO].
  14. detlion1643

    client -> server safe communications

     Thanks for the words.   Basically they won't make custom rules or cards. They could only modify the look of anything though.   Envisioned like this: Server tells client -> player was dealt these cards for their hand. The client goes ok and renders them however the plugin creator defines. When playing a card, the plugin creator calls a method via the supplied framework, framework tells the server to play card x, and the server figures out if it's a valid play or not. All the rules and checks and everything were planned to be server side.
  15. I am currently building out a server/database on my local machine to go along with a client core. The core of the client will interface directly to the server. The actual client files will be open sourced, the core client exe and framework itself will be closed. Others can use the framework to make their own "client files", and the methods from the framework will interface to the server so others don't have to, they can use the supplied api's. The client files are compiled dll's that can pretty much do anything that people want to as long as they code it. With that said, inside my supplied framework I mentioned is where the real "client" to "server" communication happens.   Let's say I supply a method called "private eCreateAccountStatus CreateAccount(string Email, string Password) { ... }".   Now, anybody can call that method using my framework, and that method isn't vary harmful to the server, as it just checks for an account with that email already and creates it if not existing.   The game in question is going to be very much like a traditional ccg/tcg.   Now, let's say in a game, we need to tell the server we are playing cards from our hands. Should we provide a direct method of "PlayCard(int CardID)" and do the approprate card checks on the server (does the player have the card in the first play, do they have the resources to play it, is the game in a state where it can be played, etc). Or does this open up a vulnerability since players could pass in any card.   The reason I mentioned the "Client Files" earlier is let's say in a provided default GameBoard.dll I place our hand in the bottom and the opponents hand in the top of the screen. Someone doesn't like this design and provides their own GameBoard.dll that places their hand on the left side and the opponents on the right side of the screen. The Client Files just provide the design for where things get rendered.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net 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!