erpeo93

Members
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

315 Neutral

About erpeo93

  • Rank
    Member
  1. Thank you for the reply. My game is an mmo, so the first option is not really an option. Yeah, with a particle system it's quite easy to simulate ice, water, and fire, and for sure I will experiment with particles in the next months. Can you point me out to some good in this direction? Because, thinking about it, if I would be able to find a good particle effects for all of these, then handling them "continuosly" is trivial: the only thing I have to do is adjust and change the emitter parameters, and that's it. Also merging them becomes pretty trivial: two emitters becomes one emitter. edit: I should say that I want the server to think about those surfaces as simple rectangles or something really simple like that, and the clients just render the effects on top of that.
  2. Hi all, in the top-down 2d game that I'm developing, I would like to create a system that can handle water surfaces as well as "icy" and "firing" surfaces, handling of course also their interactions and maybe sometimes "merging" them. Logically, my engine can easilly think about them as rectangles, that allows me to do everything I want speaking in term of gameplay. The problem is that I know absolutely nothing about how to render these effects in a realistic manner, not to mention their interaction and merging. (for example, how to dynamically render a small lake that is growing its dimensions due to rain water?, or how to render an icy surface that slowly becomes water under the effect of the sea and merge it with a nearby water surface?) I would like to be pointed out to some resources that you guys know are good... I think the direction to go is a fluid simulation system, but yet I've never worked with one of them. I found this book, that seems pretty nice and on target: https://www.amazon.com/Real-Time-Visual-Effects-Programming-Gaming/dp/9812874860 but before spending 100$, it would be good to know if it worths them, or maybe you know something better. Thank you very much. Leonardo
  3. I found this digging  the web... https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable It's true? should I wait for recv to return 0 instead of setting SO_LINGER?   The final process will then be: -server calls shutdown on writing side -So, the client reads until the recv call return 0 (that will happen only after the server calls shutdown right?) -then, it just closesocket. -the server's call to recv will now return 0, and it can now safetely call closesocket.
  4. That's unlikely. While it is true that clients will not receive data as long as the buffer is full (but then, just read more often!), as soon as the buffer has room again, clients will receive the data from resent datagrams. Unless... the server crashed in the mean time or someone pulled a cable, or several minutes passed with no sign of life from the client whatsoever.   Here, there is indeed a possibilitiy that clients are not getting the message, that is if it exceeds the send buffer size. Normally this is harmless, the call to send will just block and will copy data in smaller chunks until none is left, then eventually return. But with non-blocking send, you get EWOULDBLOCK and that's it. If you don't check for send being successful, it just goes into oblivion and you never know. Be sure you do check the return code and errno.   Yes, that is the only way of knowing the client has gotten the message, but the approach makes little sense. You already know for certain that unless catastrophic things happen (pull cable, crash, etc) the client will receive the message. You also know that data is delivered in-order, i.e. any message referring to what happens on the other island will be received after the "move to new island" message is received. Both things are guaranteed by TCP. No issue with consistency there. Thus, resending does not make any sense. If the connection is broken, the resend will not make it through either, but if there is any way of getting the data to the client, it will be received. And, it will be received before anything you send after it. Your manual resend won't, it will be received after whatever you sent last (so it isn't terribly useful for maintaining consistency). TCP can be tricky if one wants some particular things which are not directly supported by either the protocol or the API. You cannot tell how much the client received (not easily and portably, anyway), nor whether the connection is alive at all, other than by sending and getting a connection reset or destination unreachable error (even if you get no error, that still doesn't mean much since the condition may change the next instant), or by closing the socket and checking the return value. Neither one is particularly useful in practice(especially closing the socket is not if you're intending to continue sending!). Luckily, almost every time when you think you need such a functionality, you really don't. Just send your stuff and rely that it will work. Your sends might not arrive with the lowest possible latency, but they will arrive, and in-order. Or, well, sometimes they won't, but then you will eventually get an error, and there's not much you could do to remedy the problem anyway. -- close socket, and wait for the client to connect again. Or, as hplus0603 suggested, consider UDP instead. UDP sounds very scary because it is unreliable. But the truth is, it isn't unreliable at all -- the datagrams arrive just as reliably as any other packet, 99.9% of the time it just works. Only, UDP doesn't strictly guarantee an order, nor does it resend packets in those 0.01% of cases where they get dropped -- but in a realtime application like a game (or think telephony!) this is often not something you would want anyway (who cares about what was 5-10 seconds ago?). But if you do care because one datagram was particularly important, you can still just resend the datagram.   very useful reply, thank you. I'm absolutely considering udp at this point, I'm just waiting for me to have anything more compelling to do on the game that to change a protocol that is working at the moment.   So, to say that one last time, IF send() returns me the right number (the total size of the packet), then the packet WILL arrive at destination (unless catastrophic events of course) and it will arrive before anything other that I send after this send, is that right?   If it's so, then it means that the client is closing the connection at some point, for a reason that I don't know at the moment... because the server of course keeps running and pushing packets all over the place.     Noooo, I know the reason... I spotted the bug in this exact moment... After successfully sending the critical message, the server calls shutdown on the client socket, and then set a boolean that is "loggingOut" Then, after having done all of the network stuff, the server checks if for every player the loggingOut variable it's true, and if it is so it calls closesocket. Of course, when there is a snall number of players, the call to closesocket is NEVER done before the packet is actually delivered, because the receiving buffer isn't full. But when the receiving buffer is full, even if the call to send succeds, the packet hasn't been delivered, but the variable loggingOut is setted to true anyway... and here we go closesocket is called. What should I do? should I set a timer? wait for a special message?   Man, that was nasty.    But of course now I've implemented that useless acking thing, that will be exactly what I would do if I was using UDP... I will keep it off hand so that I have it ready when it comes the time to switch to udp. what do you think about using udp for client-server and tcp for server-server?
  5. Yeah, at one point probably the client is flooded with packet from the server (In some moments the client was receiving updates for maybe 100 players, and so the buffer gets filled out very quickly... in fact the bug never happens until I spawn a big number of players. I'm not sure that I'm reading data quickly enough when there are 100 players in a small area (probably not), but how can I determine if it so? And if it is so, what can I do?
  6. If you need exactly the guarantees that TCP gives -- every byte is received, in the order it was enqueued -- then using TCP is great! Note that TCP doesn't GUARANTEE that the data gets there -- it gets there, or you (eventually) get a timeout error. I mean, if the cable is cut or the computer turned off, no data will actually make it there. Most game traffic can work better when the guarantees are different, though. For example, why re-transmit old object state, when you have newer object state available? And if each object update is un-ordered compared to each other, why delay the update for object B just because the update for object A was somehow lost? It is in these cases that you CAN do better on UDP than TCP. But if that's not important to you, TCP can be just fine.   Yeah, I totally agree with you on the old object-state thing. Yesterday I implemented acks for the critical packets, and of course it worked. So I guess that at this point tcp is basically useless to me, the ideal protocol for my game is clearly one that sits on top of udp for the client-server communication.   For my server-server communications, although, I think I will stick with tcp: I know that my servers will be always very near one to the another, so there wont be performance problems or overhead in the tcp ack mechanism. And of course there are more critical packets server-server than client-server, it would be hard to mantain all of them in memory.   It's safe to use udp for client-server communications while using tcp for server-server communications? Moreover, IF I know that the host of the tcp communication are very near and will always have room to receive the packets, can I assume that if send return me the right number, the packet will be received by the destination?
  7. "No indication of failure to deliver is implicit in a send()." Locally detected errors are indicated by a return value of -1.   that's on the man page, so I guess I was right... the client isnt really receiving the bytes. BUT, at this point I'm asking, considering this fact, How can my server be sure that the packet has been sended? the only way is to wait for an acknowledge right? but now I'm implementing a reliable protocol by myself, which is exactly the reason I used tcp over udp...
  8. Hi everyone, I'm building my mmorpg from scratch, it's going pretty well I would say. ( I will surely open a development blog soon) My network protocol is built on top of tcp, and a couple of days ago I implemented a way for me to spam other players in the world, that open their own connection to the server. (for now I'm running both client and server on localhost). Everything is fine, (indeed I'm surprised to see 300 players easily handled in these conditions) except for a sublte bug that I'm having from yesterday.   My world is subdivided in islands, and when a player changes island, the server sends the player information about the new island, so that the client can open a new connection to the other server. (Yes I'm running 2 server on my pc) When the numbers of players increase, sometimes the client don't receive that "critical" message, and so the connection to the other island never happen, even if the server has sended it. (or at least the call to send() returned the right number of bytes).   So my question is: could it be the case that even if the call to send() effectively returns the right number of bytes, in reality the clients dont receive them because their buffer is too full? that would be explained by the fact that all is running locally, so I guess both client and server are sharing the same tcp receiving buffers at their base. Shound I implement an "acknowledge" for those critical packet? so that until the server don't receive the acknowledge it continues to send the critical packet again and again? That would sound a bit odd, because that's the principle around tcp right? but I'm pretty sure the bug is not something in the logic of the game, is just that the server call to send return a "fake" value. Maybe in real world scenario this will never happen?    Thank you all, Leonardo.
  9. Hi,   I'm developing the engine for a 2D mmorpg (things are going quite well, as soon as I have a "playable" thing, I will surely post about it :) ). The thing I'm having problem with is the terrain generation. (of course I am a totally noob in that field).   I want to generate a tilemap with various "heights level, and of course I could use one of the many technique/algorithm available... The problem is that while for now when I generate a chunk tilemap I can generate it totally indipendent from what's around it because for now there is only one height, if I need various heights in the maps of course I can't, because I can't just put the heights on the chunk tiles without having informations about the sorrounding things.   The server of course just send you the world seed, so the problem is that when you build a chunk, probably you haven't build the sorrounding chunks yet... Let's say I want to generate the chunk at position (2,2): of course I can't randomly put the terrain heights chunk by chunk: that would be pretty horrible. for the chunk (2,2) I would like to be able to know what the tilemaps are  in the chunks (1,2), (3,2), (2,1), (2,3) ecc, but I don't have them!   I'm basically searching a function that given the X and Y coordinates of a "chunk", and given the world seed, tells me what will be the tilemap for that portion of world, placing "heights" around it in a reasonable pattern but of course the only information about what's around me are the coordinate of the chunks.   Hopefully you will understand the question, and probably it's a really simple thing.   Thank you. Leonardo   ps: what are the best book/tutorial/paper/article to learn the basics of procedural content generation?
  10. I don't think so -- you can easily calculate which animation (and frame) to play by knowing when an action started, and how long ago that was (in times.) Your game could run at 144 Hz -- if it knows that the "fireball" animation started 1.3 seconds ago, it knows to display whatever frame is 1.3 seconds into the fireball animation.     Ok, so the server could just know when the player started walking, fishing, attacking ecc, update the world accordingly ( if a player fish for more then 3 seconds then spawn a fish). But I now need to send all the other players the "action timer", right?   So to any client I will tell:   player1 is attacking, the action started 3 seconds ago player2 is fishing, the action started 4 seconds ago player3 is walking right, the action started 10 seconds ago ...   this way the client will have the possibility to calculate all the other players animation status.   That seems very reasonable to me: this way, even if a client doesn't receive packets for a couple of seconds, it could animate other player anyway, because it knows what was the starting time of the animation.   But how do I resolve the problem of sync between client and server? Because if a client send a packet at 22.00, that packet will take several ms to arrive at the server, and maybe at the time he arrives, the action is no more valid, even if at 22.00 it was. For example, at 22.01 a rock magically spawn at the location player want to move. even if the packet was sended at 22.00, the packet arrives at 22.01, and the action is not valid, even if at 22.00 it would have been. Should I keep a buffer of world states in the server memory? one for 21.58, one for 21.59, one for 22.00, one for 22.01?   Other way to accomplish that? Could I just forget about "packet time"? (and of course consider only the packets within a certain "time range") I mean, if the time server is 22.01, I accept packets that are 22.00, 22.01 and 22.02, but not packets that are 21.54, 22.08.
  11. Thank you for the quick and complete answer. Of course the "forced messages" would have been those that don't need immediate feedback: login request, request to sell an item ecc... Anyway probably it's best to go with tcp first, and then in case switch to tcp. You're saying the server send updates 10 times per second... these updates contain also animation data right? If it so, it means that if my game runs at 30 fps I need to show every animation frame at least 3 frame... is that right? Isn't it a bit risky? I will surely make use of the "fake" animation that you have mentioned, thanks for the advice. Just to clarify, let me make another example. -Client want to move right: the time is 22.00 The client start simulating the movement, updating the position, and show animation frame "walk right 1" -the client send a message to the server containing the action (move right) and the time of the action (22.00) -the server receive the packet, and checks if the client is allowed to move right. If it is, update the player position, keeping in mind that the server time can differ from the client's one, due to the packet delay, so for example the packet arrive at server at time 22.03 the server has to account for those 3 minutes when sending back response to the client: if an animation frame lasts 2 minutes, the server will response "walk frame 2". If the player wasnt able to do the move, the server simply doesnt take into account the player action, and it will send back the world status as nothing has happened. Now the problem is: the client told me that it would like to move right at time 22.00, but when I receive the message my time is 22.03. What do I do? Going on to the database question, Surely storing the abilities as simple text in the player table is an option, something simple like "fireball10 icecone5 heal3... but what for all the world object? Here I absolutely need a master table, right? Something like: ObjectID name position status 001 rock (20, 30) broken 002 magic sword (50, 10) full 003 sword (80, 20) broken Of course, I Could drastically reduce the entry making the world not persistant, not allowing dropping objects ecc. But I would like to have persistant world also after a server crush or restart. Any suggestion on this problem? (Storing the player inventory as text is not an option, every equipment piece could have several magic abilities) Maybe I could subdivide the object in various DB Instances? For example objects of world from 0 to 100 are stored in an instance, objects of world from 101 to 200 are stored in another DB instance?
  12. I'm currently trying to lay some code that will allow me to build an online multiplayer rpg.   I've pretty solid understandings of both newtwork protocols, (IP, TCP, UDP ecc) and of relational DB. I'm in the process of building my own network protocol over UDP, following the gaffer on games tutorials, and as soon as I finish writing the protocol I will begin coding the API to interact with the DBMS. I'm using C++, but not in a OOP manner, and I'm not using any framework or library: this way I have more control over what I do and I can learn much more. I will probably use MySQL as DBMS.   Now coming to the game:   The game is 2D. I've many different worlds procedurally generated, and the players will be able to move from one world to another in certain specific ways. At the moment I don't know if there will be a limit to the players able to play in the same world, I will decide later, also considering the budget and the performance I get.   The world is fantasy, so it's populated by monsters, NPC, environment elements, ecc.   My idea about the client-server protocol is this: The server will perpetually send clients data about their positions, what action they are doing currently, and what are the static and dynamic objects sorrounding them.   EDIT: another question. I would like to avoid sending the same object many times if it has not changed status, position ecc. For example, if there's a rock, I just want to send the rock position in one packet. I should be able to just send "world updates" to the client, right? So the routine will be something like:    -for every player, the server checks what has changed in the world, and send those data to the corresponding client. Right?   (of course I will spatially partition them so the server has an easy life retriving the data ).   The clients will send packets when input occours and the player would like to send the request to make that move.   At the moment, my network protocol is "virtual connected", I also have sequence number, and I've implemented a simple "packet queue" that keep track of the packet that I've sended. So I've implemented some sort of "reliabilty". Hopefully in the next days I will implement congestion avoidance and I will make some serious test with the protocol.   My questions are:   -regarding the network protocol:   is reasonable to let the application decide if the packet that it's sending has to "absolutely be delivered", or if the packet it's lost nothing occours. For example: the packets the server sends to the client are not critical: if the server sends the client the packet number 99, and that packet get losted, well in the packet number 100 there will be the up-to-date positions, object status ecc. Is that right?   something like: SendPacket( packet...) ForceSendPacket( packet..)   Is a good idea to give the applications those API?   -If I want to be able to resend a packet, Is it best to keep the data at the transport level, (for example in my queue I also keep the data for all the packets), or it's best to communicate the application that "the packet number 99 has gotten lost, what do you want to do?" (I think that this question depends on the answer given an the upper question)     I will implement a simple congestion avoidance method, something like incremental increase, multiplicative decrease: every time I get an ack, I icrease by a small amount, but every time I lost a packet, I reduce the speed by an half. Moreover, every time I correctly receive an ack, I will "take care" of the RTT, and adjust the sender speed. Make sense?     -regarding the "game": I will surely implement some sort of client simulation, and then the client's action will be accepted of rejected by the server. But of course the server will always have the last word. My question is about animation: is the server that sends client the current animation frame, right? But this way the server will have to take into account the client simulation that has already happened. Let's make a simple example:   -client's presses right button: the client starts simulating the movement, and set the current frame animation to "walk 1" -the client sends server a message saying "hey, I'm moving right, Am I allowed to do that?" -the server checks if the player is allowed to do that, and send a response saying like "ok, you can walk right, start the animation: walk 01" -the client receive the message and set the animation to "walk 01".   But the client prediction was right, and some amount of time has passed: probably the animation should have been "walk 02".   What is the best solution to this problem? animations happens client-side? or the server takes into account that some amount of time has passed, and so it sends back directly "walk 02"?   EDIT: re-reading the post, I thought about a solution: The server ALWAYS keep track of what animation is doing the player, and what animation frame is currently on, so that all the player will have the same identical result on the screen. To resolve the "startup" problem, when a client action is accepted, the server will assumes that the client has already started playing the animation, and so it will take that in consideration. But know I need a way to know how much time has passed from the start of the simulation? Could I simply say that "well, more or less the client is ahead half of the RTT with the animation regarding the server, so add half of the RTT to the "animation time". It's good enaugh? Better ways? I don't like the client sending the real time in every packet he sends...   I think the last solution is better, but I'm searching for confirm.   -considering that the game is 2D, and that I will use a tilemap for the terrain, plus every environment element (rocks, trees, rivers...) will have coordinates and status will I be able to have persistant world in your opinion? I mean, if I have a blueberry bush, and a player harvest it, I will be able to mantain that bush status over a server crush?  (I'm planning on having someting like 2000 * 2000 tilemaps, so I would say something like 2,5 millions of entities per world)     -regarding the DBMS:  Of course I will mantain the world status in the server ram, and I will update the DB asynchronously.  My critical tables are 2: the object table, of course, and the ability table, where I store which player has which ability, and at what level.  assuming that I will not make joins with these tables EVER, can I safely have a table with billions of entry? Better solutions?   Last question, very easy. Let's say I cap the player maximum for "world" at 64 or 128. But as I said, the player could change world several times/hours. Is that a simple MOG or an MMO?   As always, sorry for my english, and thank you in advice. Leonardo
  13. Hi all.  In the next days I will be publishing my first android game ( a puzzle game, I will writing on it soon on gamedev ) I've developed it entirely from scratch, with C++ and some OpenGL for texture rendering.   I'm thinking about making another game, obviusly more complicated than my first game, and I think that it will be to big to realize for just one person. Let me start saing that I am a big big fan of RPG's: even if I'm 23, I had the incredible luck to play with an amiga: that allowed me to play great games like "eye of the beholder", "black crypt", "dungeon master", "captive", "Perihelion", ecc. Of course I've also enjoyed all the great RPG's from 2000's: FFVII, VIII, X, "the witcher", "Diablo", "morrowind", "Ghotic", and many more. I'm also a big fan of roguelike/survival: "don't starve", "the binding of isaac", "minecraft", "fallout" ecc. So I think I have a good all around understanding of RPG in general. (I hope I've made yourself revive your memory with this long list... :) )   But let's get to the point: my intention is to build a 2D rpg with a consistent survival component (pick don't starve as an example), but with a great "levelling" system, that will take many concepts from that of Diablo 2. (I think that it remains the best level system of all time) Of course the goal is to center the game on crafting and looting, like any other respectable RPG.   The view will be substantially top-down, slightly "twisted" (pick that of zelda link to the past as examples) and the setting, of course, will be strictly fantasy, but not too cartoonish or darkish. (let's say half way between don't starve and zelda).   The main platform will be windows, android and iOS, and if all goes well I'm planning to add a big multiplayer support, something like 30-40 player in the same world at the same time.   I know that you're laughing at me, but don't worry, the development will be incrementally (of course): We'll first develop the simplest single-player we can imagine, then we'll pass to a more sophisticated singleP, and finally we'll implements multiplayer if we can and all goes well.   Now let's talk about the "contract" aspect (of course there is no contract, it will start as an hobby project): I'm planning to code from 30 to 32 hours/week, so it will be something like a 3/4 of a full time work. Of course it's possible that the project is too big for two programmers plus artirts, so I have to take into account from the beginning the possibility of re-demensioning the goals.   I'm basically searching another programmer to help me code the beast: I have no particular request, the only one is to love making games of course, and have a good experience with low level programming or with C++ in general, but also with game programming. I will build the engine from scratch, so probably if you use Unity or UE4 this is not the project for you.   IMPORTANT: we will not use OOP!!   Of course it will be a big, big plus if you have published even a simple game, or if you've developed one by yourself. I'm searching for someone able to dedicate AT LEAST 20/21 hours/week. My idea is to try finish the simple single player in 12-14 months, an then decide how to proceed.   For what concerns the artirts, I've got a couple of friends that are really good ad drawing, but I'm open to any other possibility. (we could hire someone or we could decide to learn and make it by ourself LOL ). Of course the revenues (if any) will be equally divided, such as the cost for artist or other things. I'm not very interested in money, so that will surely not be a problem. Obviusly at a certain point in the development we could decide to lunch a kickstarter campaign or something similar, we'll see how it goes. Again, I can not guarantee any money for me nor for you, but I'm sure that if the game ends up being more or less like I'm imagining it, it will have success. (the vast majority of 2D rpg for android and iOS are ridiculus right now).   In any case, even if I don't find anyone, I will start the project by september.   Let me know by the end of august at: leonardo.lucania@outlook.it Of course contact me also if you want to know more about the game, I've written down a lot more about the gameplay than what I've said here.   Sorry for the reeeeally long post, but I absolute want to clarify every aspect of the project, so you have more information as possible and you're able to make the best decision.english, But I ensure that my speech skills are even more awful.   Have a nice day, Leonardo
  14. 2d/3d Artist seeking Programmer and/or Team

    I've sent you an email. :)
  15. thank you very much guys... very useful idea. I will try to do my best.   Leonardo