Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

144 Neutral

About Chumble

  • Rank
  1.   I've been using partial transparency in the sprites. Art isn't really my strong point so I'm considering everything I have to be placeholder, but I've done nothing fancy with it. Just made some stuff in paint.net as a .png with transparency and loaded em in.   The scene is sorted back to front before every draw. You've lost me on the part about "early rejection" though..     I do (although I didn't know it was called a texture atlas). I have a single .png containing my ground textures in a grid. On initialization, I create a texturemanager class to load in the individual sprites to prepare them for use (though I suppose if I wanted it to be more memory efficient I could load them in on demand.. but I think that would just trade off processing power for memory).     I do. At the time it was between an array and a vector and I found vector was more useful for what I was doing.   I'm a bit lost looking at your code, I guess I'm not advanced enough in C++ to understand that at a glance. I don't know why you'd need more than one way to sort it .. I think it comes down to your level/slice being a more advanced implementation than I am doing. I consider everything to be on the same "level".   For every object in my vector, I use the coordinates to calculate the "base" coordinates and the "draw" coordinates. The "base" coordinates represent the coordinates at which, if an object were to overlap, which one would be drawn on top.   Here's a crude representation of what I did:    So the green dot represents the actual coordinates stored on the object. I've also stored the height and width of the "foot" or "base" of the object which outlines where the object touches the ground. Using those, I calculate the red dot, the "base coordinates". The y base coordinate is what I use when sorting the vector (in ascending order) because if your y coordinate is higher than another's, you need to be drawn after them (to show up in front of them).   I spent a long time (1-2 months) messing with this to get it right and it involved an awful lot of trial and error considering I was just making it up as I went.       I do like the idea of having a smaller structure only containing stuff that will be drawn to the screen. Right now my code looks like drawScreen() { sort gameObjects; loop through all gameObjects { If gameObject is within a set distance from the player { gameObject.draw(); } } } But I could change it to drawScreen() { loop through all gameObjects { Find all gameObjects within a set distance from the player Add them to drawObjects } sort drawObjects; loop through all drawObjects { gameObject.draw(); } } It will probably be more efficient.
  2. I am developing an isometric style game. My main game loop is   Process Input Update Draw Screen I have one c++ vector that contains all the tiles and objects that I will draw. I have them in this structure for one reason: Since this is isometric style, I need to sort this structure by depth so that, when drawn, objects properly overlap each other. This much works fine.   I am implementing more features now that involve several moving objects on the screen. Here's where I started crashing.   I was crashing because I tried to move objects in the vector while the drawscreen routine was reading from it (or sorting it). My solution was to perform all movements in the update function so that by the time drawscreen executed, all manipulations have finished.   This appears to have caused a bit of a performance hit that I have yet to explain. But before delving in too deep in debugging this, I wanted to run by current setup by you guys to see what you thought. I have no idea how this stuff should be done, kinda just winging it as I go.   Does it make sense to keep all objects (tiles, enemies, players) in a single structure? It seems like a bad idea.. I would have rathered a different structure for each type, but that makes it much less efficient to sort and draw them in the right order.   Is there anything else that stands out as being weird or wrong?   Thanks
  3. Chumble

    Library Hesitation (OpenGL)

    This has cleared up quite a bit for me :) Thanks guys. I think I'm gonna read through http://openglbook.com/ to get a better understanding of OpenGL, then later down the line when I decide to implement it, I'll see what I wanna do for a "binding".  Thanks!
  4. Seems like I'm posting a topic here every week so if you're on this forum often, you've probably run into me at some point.   Anyways, I'm making a 2D networked game in Java as a project for learning the language. So far I have only used libraries that were immediately available to me. My thought process behind this was I wanted to learn Java at the most basic level before incorporating libraries to "do things for me" or simplify tasks.   I'm not sure at what point I should change this mindset. Currently my game allows for multiple people to join in, run around, and collide with trees (just got my collision boxes working yesterday, super pumped!). I don't really know what direction the game will go in, I'm just trying to set up a lot of back-end stuff... dynamic systems for which I can start layering on content.   I started thinking about lighting. Now, my experience with lighting has been .. limited. I created a 2D tile-based game in a proprietary programming language designed to create interfaces for medical software. My lighting calculation was incredibly crude and basically involved "Loop through every single tile. For each tile, calculate all tiles between this tile and the player. If there is an object on any tile in this set of tiles, then the player cannot see this tile". It created a very blocky LOS lighting calculation. Some optimizations were made to make sure I wasn't checking tiles twice but overall it took about .5 seconds to move from one tile to the next.   Now, with my current game, it's not really tile-based anymore. I mean.. there are TILES (which I really just use as squares of floor), but all objects, including players, can be moved on a per-pixel basis. Which really means I need pixel-based lighting. I also wouldn't mind incorporating some fancier shading effects, although I really don't know much about them.   This is really the FIRST time I've ever used a real language and created GRAPHICS. I used C++ for a while and did all console based applications. I started to learn DirectX stuff but got caught up with Windows programming. I don't really know .. how a lot of this stuff works. I understand DirectX and OpenGL are designed to help software communicate effectively with hardware... that's about where my understanding ends.   So.. OpenGL. I see lots of people recommending LWGL (I think it's called), assuming it got popular after Minecraft. Do I need to use that? Can I just.. use OpenGL directly? OpenGL is *already* a utility to help draw graphics and if this is my first time delving into something like that.. I would kinda rather not use a library to "do everything for me".   So .. questions: 1) Is it possible to learn OpenGL without incorporating another library to help make use of it? Does it make sense to do that? 2) I'm enjoying Java2D so far, but I don't wanna go so far into it that when I finally DO decide to do some fancier stuff, I need to re-write my graphics 'engine' (I can call my draw screen class a graphics engine, right? :-P ) 3) More of a general question.. what does it mean to LEARN OpenGL (or DirectX for that matter)? Is OpenGL just a set of libraries in itself? Multiple languages can USE OpenGL.. how is that possible if they all have their own syntax? I am woefully in the dark about how this works.   Thanks for reading, WhateverMyNameIsOnThisForum       Edit: Tuns out most of this stuff is discover-able with Google if you use the right terms. Seems like any language implementing OpenGL requires some sort of wrapper to utilize the functions. A more "standard" one for Java is JOGL. I guess the LWJGL is just another?
  5. I have uploaded a video of this. In this video, I connect to the server, can run around... generally fine. Still not perfect.   Then I connect several simulated clients that just move in circles. As you can see, for each client connected, the performance just gets completely shot.         Edit: I'm an idiot. Had an extra sleep inside the loop on the client side. No idea why it was there. Got rid of it and I'm good.
  6. Ok - I have added the above features to varying success.     When a player presses a directional arrow key 1) Check to see that the corresponding "keyDown" flag is not set. 2) Set the "keyDown" flag for that direction 3) If there is a "keyDown" flag already set for an opposite direction, clear it.   When a player releases a directional arrow key 1) Check to see that the corresponding "keyDown" flag is set. 2) Clear the "keyDown" flag for that direction   After either of the above occur, I "compile" the direction to a single int. 0 = no direction, 1 = Up, 2 = Up/Right (etc, clockwise until 8=Up/Left).   I create a new network packet with this int and send it to the server. The server gets this message and updates a new field on the player object called moveDirection.     There is a new thread running on the server called UpdateThread. 1) Loop through all entities. If the entity has a "moveDirection" > 0, update their position server-side. 2) For each entity, if it is found that their moveDirection had changed since the last loop, broadcast this new moveDirection to all clients. 3) Increment a counter. If the counter is > 100, reset the counter and broadcast the actual entity coordinates to all clients (to ensure they are synced). 4) Sleep for 10ms   The client's main update loop performs a very similar process to the server's UpdateThread 1) Loop through all entities. If the entity has a "moveDirection" > 1, update their position client-side. 2) "Sleep" for 10ms (since it's not in a thread I needed to make my own sleep function .. just uses a while loop to pause execution for X ms)     So.. the result.. When connecting to my own server using, it seemed moderately OK. A little twitchy as the server corrected my position.. slightly more than I would have guessed but tolerable I suppose. When connecting a second client to the server, suddenly performance was cut in half. I cannot imagine why as the loop running through two entities instead of just one should still only take a minuscule amount of time. But the end result was the players seemed to move at about 50% normal speed. Speed was decreased by another 50% with a third client.   Also, when connecting to myself using my external IP address, performance right off the bat (even with a single client) was very sloppy. I could move in a direction but I was jumping around almost constantly.     The more I type, the more I think something has to be wrong client-side. If the client is just getting a message that "Player 1 is moving left", there should be no reason why that player would move slower between the server synchronization updates that only happen once a second.   Anyways, if anyone has any further thoughts, feel free to post them. If not, I will continue plugging away at this to see if I can improve it. I'm hoping I haven't already hit the limits of TCP.
  7.     o.o     .. seems much more complex than what I need. I don't plan on doing anything with projectiles and shooting bullets, etc. I think.. this is one optimization I will hold off on for now because I'm either going to go crazy trying to understand it or code it. I think I should be mostly OK without it.
  8. Maybe I'm being a bit dense about this, but my point about NOW is that the server has the final say as to who is where. The best the server can do is try to relay this information as accurately as possible.   Yes, players will lag, and their position will be slightly off at times.. seems the best I can do is have the server update them at regular intervals to make sure they're on track.   You obviously know what you're talking about and again, I'm not trying to simply contest you. I accept that I am wrong, but in order to come to the correct understanding, I need to relay my thoughts.   I'm going to set up an example. There are two players, both are standing still.     -------------------- T=0 Player 1 starts moving right. Begins moving immediately client-side *(1)   T=1 Server receives the "Player Move Right" message. Broadcasts to all clients that Player 1 is moving right. Player 2 still sees player 1 at the original location. Shoots at player 1 (Sends "Shoot" message to server).   T=2 Player 1 and player 2 get server's "Player 1 is moving right" message. Both player's screens are updated appropriately (Player 1's screen is adjusted, if needed). Server gets the "Shoot" message from Player 2. Calculates that player 2 missed player 1. Server sends the .. animate bullet message?.. to all clients to draw the bullet..?   T=3 Player 2 watches the bullet miss and cries in frustration --------------------   *(1) - Using as accurate of prediction as I can come up with.   This seems like a very possible but understandable situation. This is a networked game and networks have lag. I don't see how adding a timestamp to each message helps. ...... unless you're saying that the CLIENT sends a timestamp to the server as well?   I don't think it would help the situation above because that is really an extreme situation, but if it was a situation where Player 2 fires at player 1 at T=1 (and sent this message to the server), even if the server didn't get the message until T=3, the server would remember that player 1 was at the fired upon position at T=1 and generate a "hit" anyways? The more I type this the more I think I still have this wrong.   :-/
  9.   No, but I figured I'd just have the server keep track of that. If the player gets some kind of speed buff, the server will know.. it will adjust the speed server-side so when the player requests to move, it uses the current server-side speed.   As this game is really just my own little training project, I realize it will never be flooded with people, much less flooded with people who feel the need to cheat, but I'm trying to incorporate some "best practices" so that when I do work on something legitimate, I'm used to doing it right.     That's gonna be a tough one. I can't imagine more than 10 or so objects will be moving on a player's screen at a time. I've already tried to limit how much traffic is sent to the players by only updating their surroundings rather than the entire game, but it needs more work. I guess this will be a trial + error effort.     That.. is interesting. I'm having a little bit of a tough time wrapping my head around that. Why wouldn't I just use NOW as my time? As long as the server is sending the most recent information and the clients are updating with the most recent information, why do I need to check times? I'm not trying to contest you, I just don't understand it. Could you possibly give an example?     Thanks, Jeremy
  10. Thanks everyone for the replies!   @Satharis, I accidentally pressed the down arrow on your comment instead of the up arrow and it doesn't seem to let me change it :(     Maybe I'm over-thinking it but I think I'd rather just say "Move + <Direction>" rather than pass in an actual value. This way I think it helps prevent cheating maybe?     If I do a check server side and confirm that the player did not change direction/speed, do I even need to send the updated position to the clients? If the clients all know a player is moving, I can use some client-side prediction to show their position.. I guess that could get out of sync pretty quickly. I wonder how often I would need to update the clients with the position?
  11. Sorry, I guess I wasn't clear. I am not sending input messages to the clients, I am sending updated coordinates.   Yeah, I know UDP is generally reccomended .. I went through lots and lots of "TCP vs UDP" threads before sticking with TCP...Basically because TCP was easier. I'm starting with easy stuff, getting comfortable with it, then once I understand its limitations, I'm moving on to more complicated optimizations.         Hmm.. yeah, that could work, I'll give it a shot. Thanks!
  12. Preface: I am making a 2D networked game where each player controls a single character. Primary goal is getting more comfortable with Java, but I'm having fun making it too.     This topic has two parts. The first deals strictly with Java and implementing the key listeners to move a player.   The second I would like to pretty much detach from Java completely and deal strictly with pseudo-code or simply documentation.       1) Player Input in Java   Currently, my client GUI has a JPanel with addKeyListener(new ClientInput(this)); My ClientInput extends KeyAdapter and has functions for keyPressed, keyReleased, and keyTyped.   First problem is with continuous input. Just like when typing on here, if you hold a letter down, it is subject to your input delay. Press and hold "f" and you see it types one "f", you get a delay, then a steady stream of "f"s. At first I thought it was because I was using keyPressed instead of keyTyped, but it seems Typed does the same thing. How can I deal with this issue? I'm assuming I'll need to use something other than KeyAdapter.         2) Networked Movement Architecture   Preface note: I am using a TCP connection.   I have started everything with the most basic and straightforward implementation. As of now, this is how my client/server function:   a) Client presses "up" - sends "move up" message to server b) Server moves the player up, sends "move up" message to ALL clients c) All clients move the player up   As I said, this is the most "Brute force" method I could come up with. That was the idea - start simple, optimize later (as I've been told on several occasions). Well, I had 2 friends connect and we all started running around .. took about 5 seconds before all the clients crashed. It seems the server sent a null network message to everyone for some reason and everyone crashed. I am certain this is related to the high volume of messages as when we all re-connected and moved slowly, it worked. But moving steadily faster over time.. null message again. The server stays up and running, which was weird.   Firstly, does it make sense that 3 players connected to a central server, sending about 30 messages per second and the server with a thread for each client responding with 90 messages per second would cause problems? I know it seems like a lot but I kinda would have thought it could handle much more.   Secondly, I think it's time to look into a couple optimizations. I think if I can figure part 1 out, I can at least slow the player input down a little bit and lessen the number of messages sent. After reading through some other posts, I've gathered that this is a popular architecture:   a) Client presses "up" b) Client performs client-side collision check. If it fails, end here. Else.. c) Client moves up (1). Sends "Moving up" message to server d) Server gets "Moving up" message. Sets a "moving" flag to indicate this player is moving up. e) ??? Update Thread ??? on server - every X ms, check for moving flags, update positions, broadcast updated coordinates to all clients f) Clients get message from update thread. Update coordinates to what is broadcast. g) Client releases "up" h) Client stops locally, sends "Stopped" message to server i) Server gets "Stopped" message. Clears movement flag.   This would involve adding a new thread to my server, the Update thread from step "e". I guess all it would do is store the "old" value of player positions and check the movement flags for each player (every X ms). If it is set, update the position of the player and send a message to all clients letting them know the player had moved.   (1)* I realize in this step (c), I would need to implement some prediction. Depending on the current latency, this may cause the player to stutter along as the server constantly corrects the player's position. I may end up needing to force a delay in here to make sure the client doesn't update the position too quickly.     This adds three levels of optimization. The first is the client doesn't even bother sending a move message if client-side collision fails. I realize there is a chance for error here - if the client has bad information, the client could fail collision even if there's really nothing there.   The second is limiting the number of messages sent to the server. The client will only send a message to indicate they've started moving (in a direction) or stopped moving (in a direction). The client will probably be moving a lot and updating their direction constantly, but probably not 30 times a second, thus limiting the number of messages sent to the server.   The third is capping the number of messages sent to the client. The update thread will only broadcast a message every X ms instead of on every single client move message. While this might cause a slight delay, I don't think it will affect my game too badly.     Anyone have any thoughts on this? Again, please keep anything pertaining to point 2 as pseudo-code or just steps. Not only does it make it easier for me to read, but it allows me to figure out the syntax myself (and allows non-Java readers to make use of it too). If there's nothing wrong with this.. great! Hopefully this can serve as a resource for others with the same issue. If there is though, please don't hesitate to point it out.   Thanks, Jeremy
  13. Chumble

    Network Message Getting Garbled

    @LostIdiot: No go on this. I did find something very interesting though by accident.   1) I connect one client, move around a bunch. I don't see the changes on the client but I can see the server is updating correctly. 2) I connect another client. The server sends the full map to the client and I can see the CORRECT position of the first client. I have no idea why. I even tried changing my server to re-send the entire map to the client every time someone moves but that doesn't work.   Somehow the initial send works and every subsequent send does not.           Edit: I ended up setting up a URN for each entity and sending "update" messages to change the position of a specific URN using 3 ints rather than sending over objects. It might make my work harder later but it works for now. I guess unless anyone else has any input on this, we can call this "solved".
  14. Chumble

    My RPG/Dungeon Crawler prototype

    Took a peak at the video - I like it. Brings up a little nostalgia. Was there a question with this topic?
  15. Chumble

    text based (not MUD) MMO

    One direction you might want to consider is a "Massively Singleplayer" game. I think Spore kinda started the concept. Basically you play a singleplayer game but interact with things that come from other player's games.   So lets say someone creates a friendly healer and he's playing his singleplayer game. His character is uploaded to the server. At any point in anyone else's game, they may see and interact with his character (controlled by an AI).   Just a thought :)
  • 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!