 Show Posts
|
|
Pages: [1] 2 3 ... 177
|
|
2
|
Games Center / WIP games, tools & toy projects / Re: Pseudo Voxel Expriements
|
on: 2013-05-13 18:36:56
|
|
I'm using LIBGDX - but LWJGL and Android
It doesn't render anything off screen
Yes it's slow, but fast enough (runs at roughly 700 fps on my local PC)
Clearing entities is a intricate process for performance reasons (viewable and shadows). Reload the whole world every time would kill it.
Cheers,
Kev
|
|
|
|
|
16
|
Game Development / Networking & Multiplayer / Re: Suggests for a 2d networked game
|
on: 2013-04-24 11:23:46
|
|
I don't think I said you were trying to confuse people or that UDP was better than TCP - in fact I think I said (maybe I mistyped) that they both have their place.
Calling the quake3 protocol a rare case is a bit odd though - it's a pretty common case for the type of games people want to network here. I've got N entities running round a map and I want them to shoot at each other. Pretty common I'd have thought. Though as I said if your model isn't that then it doesn't fit.
The only bit I took issue to was the "regurgitated "i heard that you do it this way"".
Cheers,
Kev
|
|
|
|
|
17
|
Game Development / Networking & Multiplayer / Re: Suggests for a 2d networked game
|
on: 2013-04-24 10:47:12
|
TCP is slower only because it ensures packet ordering - which means if you do get packet loss then you have no chance of getting a later packet since the TCP stack is going to wait for the earlier ones. Nagles sorts out the TCP window/buffering issues. UDP works better for data where your game/app is capable of carrying on even if it loses some packets. i.e. movement data - if I send positions: Time = 1 - Position = W Time = 2 - Position = X Time = 3 - Position = Y Time = 4 - Position = Z And I lose a couple of packets so I receive: Time = 1 - Position = W Time = 4 - Position = Z I can ignore the packet loss since I can get the later packet at time 4 and update to that position. TCP would delay you getting the packet at Time = 4 until it had managed to successfully resend 2 and 3. So *if* this was your networking model UDP would certainly be more tolerant to packet loss and faster than TCP. It's a little more complicated when you want to do it in a real game because you'd like to be able to show smooth movement between point and you might now have the data - delta compression helps a bit here. That said, knowing that your data channel is reliable lets you do some other optimisations on the client, so in certain cases TCP is way smarter way to go. For instance if you have no direct control over the actors in your game (think RTS with orders rather than shmup with direct control over your space ship) then you use TCP to great effect. Knowing the roughly consistent lag of a player and being able to reliably send an order to a server means you can loose-step things into place. (see HeadQuarter that one of the guys here wrote years ago). I wrote a blog on this ages ago - so long it's dead on my site, but the power of way back gives me: http://web.archive.org/web/20101228192125/http://www.cokeandcode.com/rtsnetworkingFWIW, I'm not saying "i heard you do it that way" - I've implemented systems using UDP, TCP and a combination of both for games and applications. Live video codecs is a great example for instance where old data isn't very relevant once you've got a new key frame. HTH Cheers, Kev |
|
|
|
|
22
|
Games Center / WIP games, tools & toy projects / Re: Pseudo Voxel Expriements
|
on: 2013-04-15 11:41:26
|
Packet loss, packet loss and packet loss  For this project at least it's a matter of syncing character positions - so I'll probably implement some sort of delta compression type thing. Assuming I carry on the game as a player controls a single hero in the world I guess. Cheers, Kev |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
)
