# detlion1643

Member

55

285 Neutral

• Rank
Member

• Role
Programmer
• Interests
Design
Programming
1. ## Understanding probabilities of getting certain items?

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. ## C# Understanding probabilities of getting certain items?

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. ## Non realtime game server (no physics) - event driven servers?

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. ## Non realtime game server (no physics) - event driven servers?

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. ## Non realtime game server (no physics) - event driven servers?

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. ## Understanding the difference in how I should be drawing lots of objects

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. ## Understanding the difference in how I should be drawing lots of objects

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. ## OpenGL Understanding the difference in how I should be drawing lots of objects

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. ## 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. ## 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. ## 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. ## 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.

14. ## 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. ## client -> server safe communications

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.